#1863 LOW V1.1: ping between associated xo's generate duplicate responses with lazy-WDS APs

[Zarro Boogs per Child]

#1863: ping between associated xo's generate duplicate responses with lazy-WDS APs
-----------------------+----------------------------------------------------
  Reporter:  jcardona  |       Owner:  rchokshi
      Type:  defect    |      Status:  new     
  Priority:  low       |   Milestone:  V1.1    
 Component:  wireless  |     Version:          
Resolution:            |    Keywords:          
  Verified:  0         |  
-----------------------+----------------------------------------------------
Changes (by kimquirk):

  * milestone:  Trial-3 => V1.1


Old description:

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

New description:

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

--

Comment:

 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.

-- 
Ticket URL: <https://dev.laptop.org/ticket/1863#comment:2>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system