Problems pinging WDS-enabled access points.

[jcardona]

The current version of the hardware MAC does not support the new frame type defined in 802.11s (type 0x3). Because of this, mesh frames are implemented as standard WDS (type 0x2, 4-addr) frames augmented with the new 802.11s mesh fields. This causes collisions with WDS-enabled APs, in particular with APs that automatically learn about other WDS nodes.

To test:

Setup: 1 xo + 1 Linksys WRT54G Access Point v3.1 or other WDS-enabled AP

Steps:

1. Associate to AP
2. Assign static address to eth0
3. ping some nodes in the mesh
4. ping AP

Result: ping to AP will fail, no ARP entry is created for the AP

More detail: Step 3 produces broadcast WDS arp requests (ARP requests into the mesh). The AP, as it supports WDS will receive those requests and record xo as a WDS node. In step 4. the xo will send a broadcast 3-addr ARP request, intended for the AP. The AP, will reply to the ARP in 4-addr format, which will then be (mis)interpreted by the firmware as a mesh frame.

[jg]

Ok, this is a fine problem statement. Do we have a solution to this problem we understand?

[jcardona]

We've modified the firmware to accept WDS frames when the MAC-OUI differs from the laptop's. Even if the AP misbehaves by sending WDS responses to standard infra frames, the wireless interface will interpret correctly those responses. This workaround will be included in the next firmware release.

[jcardona]

Fixed in latest firmware development release (5.220.9.p9) Confirmed by Ricardo Carrano.

[jcardona]

Somewhere after wireless firmware version 5.110.19.p0 WDS support was broken. The test case in the ticket description is still valid.

[jcardona]

More info on this:

Problem goes away when putting eth0 in promiscuous mode (for instance, by starting tcpdump on that interface). My guess is that this is related to the implementation of BSSID filtering in the firmware. BSSID filtering does not apply to mesh traffic. It should also allow incoming WDS traffic and it does not seem to do so.

# pinging a Lazy-WDS AP (fails)

-bash-3.2# ping -c 2 -W 2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

# start tcpdump on that interface, which enables promiscuous mode 
# (and disables BSSID filtering)

-bash-3.2# tcpdump -i eth0 &> /dev/null &
[1] 2385

# retest (DUPs is a known issue, see ticket 1863)

-bash-3.2# ping -c 2 -W 2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=25.4 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=25.9 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=26.7 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=27.3 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=28.4 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=32.0 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=34.7 ms (DUP!)
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.94 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 1.943/25.330/34.704/9.331 ms

# kill tcpdump
-bash-3.2# killall tcpdump
[1]+  Done                    tcpdump -i eth0 >&/dev/null

# retest (fail again)
-bash-3.2# ping -c 2 -W 2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1004ms

[ashish]

Wireless Firmware release http://dev.laptop.org/attachment/ticket/4470/usb8388_5.110.20.p4.tar.gz Fixes this bug

Change log

---

Firmware version 5.110.20.p4

- Fixed ticket 901. - Fixed: Allow scan command to scan other channels if it fails on current channel.

[jcardona]

Replying to ashish:

Wireless Firmware release http://dev.laptop.org/attachment/ticket/4470/usb8388_5.110.20.p4.tar.gz Fixes this bug

Verified here too. Leaving the ticket open until the firmware with that fix is officially released.

[jg]

Javier, My problems with my WTR54GS do not occur with P4 and OFW when tested this evening at home. I suspect my problems at 1cc are more lazyWDS trouble, and that the packet trace I got can confirm this...

[mbletsas]

We do see issues with encrypted APs - pretty easy to verify, just assign a WEP or WPA key to your WRT54 and try to associate with the XO.

Also, so that we don't confuse people, 802.11s has moved away from the 0x3 frame type and uses WDS frames these days.

M.

[mbletsas]

This was resolved with the new b/mcast frame format.

M.