Ticket #1863 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

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

Reported by: jcardona Owned by: dcbw
Priority: high Milestone: Update.1
Component: wireless Version:
Keywords: Cc: mbletsas, dcbw
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description (last modified by kimquirk) (diff)

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).

Attachments

ping_request_dump.txt (1.6 kB) - added by jcardona 7 years ago.
Capture of ping request
ping_reply_dump.txt (3.2 kB) - added by jcardona 7 years ago.
Capture of ping reply

Change History

Changed 7 years ago by kimquirk

  • milestone changed from Untriaged to Trial-2

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

Changed 7 years ago by kimquirk

  • description modified (diff)
  • milestone changed from Trial-3 to V1.1

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.

Changed 7 years ago by jcardona

Capture of ping request

Changed 7 years ago by jcardona

Capture of ping reply

Changed 7 years ago by jcardona

  • status changed from new to closed
  • resolution set to wontfix

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.

Changed 7 years ago by 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?

Changed 7 years ago by mbletsas

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

M.

Changed 7 years ago by kimquirk

  • priority changed from low to high
  • status changed from closed to reopened
  • resolution deleted
  • milestone changed from FutureFeatures to Update.1

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.

Changed 7 years ago by kimquirk

  • owner changed from rchokshi to dcbw
  • status changed from reopened to new

Changed 7 years ago by jg

  • status changed from new to closed
  • resolution set to fixed

OK, the latest firmware finesses the LazyWDS problem.

Note: See TracTickets for help on using tickets.