ping between associated xo's generate duplicate responses with lazy-WDS APs

[jcardona]

Reported with two lazy-WDS APs: Linksys WRT54G and Apple's Airport Extreme, using wireless firmware 5.110.16p0.

Associate two xo's to the AP. Pinging them through the mesh works fine:

# ping -I msh0 192.168.3.101                                                    
PING 192.168.3.101 (192.168.3.101) 56(84) bytes of data.                          
64 bytes from 192.168.3.101: icmp_seq=1 ttl=64 time=1.63 ms                      
64 bytes from 192.168.3.101: icmp_seq=2 ttl=64 time=2.03 ms                      
64 bytes from 192.168.3.101: icmp_seq=3 ttl=64 time=1.92 ms                      

Pinging them through the infra interface produces duplicate packets:

# ping 192.168.1.101                                                   
PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.                        
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=11.5 ms                     
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=12.2 ms (DUP!)              
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=12.7 ms (DUP!)              
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=13.1 ms (DUP!)              
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=3.75 ms                     
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=4.37 ms (DUP!)              
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=4.87 ms (DUP!)              
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=5.37 ms (DUP!)              

Wireshark captures seem to indicate that the duplicates are created on the rx path of the xo where ping is executed.

Furthermore, mbletsas reports:

Pinging the XO from a windows host doesn't generate the duplicate responses. Pinging the windows machine from the XO does exhibit the same behavior.

For baseline purposes, when associated with our Cisco 1130 APs none of the issues mentioned in this thread show up (XO's ping each other and there are no duplicate responses).

[kimquirk]

I'll put this in Trial-2 milestone, but it may get moved to FRS.

[kimquirk]

If this could be indicative of a more serious problem with these APs, then it should get higher priority. I know we have a bug related to WPA on airport AP.

[jcardona]

Capture of ping request

[jcardona]

Capture of ping reply

[jcardona]

Further analysis reveals that the Access Point is generating the duplicate frames. This capture shows that the AP generates two WDS frames (32,34) for a single xo->AP frame (30). The destination xo responds to those two ICMP requests with two ICMP replies (36,38), which are duplicated again by the AP (40,42,44,46). The capture of the response is available here. That explains why we were observing 4 ping replies per request, and why this does not occur via the mesh interface (the AP does not relay mesh frames).

There's not much that can be done on the xo's to deal with this problem.

[wmb@…]

Since pinging from a Windows laptop does not cause the problem, the AP must be seeing some difference between the Windows and XO wireless frames. Do we have an explanation for that difference?

[mbletsas]

Yes, we do. The APs treat XO frames as WDS frames and try to establish WDS tunnels with them.

M.

[kimquirk]

Re-opening this as we are still investigating work-arounds. Once we have the ability to turn off the mesh (probably via command line) then we can close it. Today, there is a bug that the Network Manager will turn it back on if you use the iwpriv command to turn it off.

Assigning to DanW to look into.

[jg]

OK, the latest firmware finesses the LazyWDS problem.