Ticket #901 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

Problems pinging WDS-enabled access points.

Reported by: jcardona Owned by: ashish
Priority: blocker Milestone: Update.1
Component: distro Version: Development build as of this date
Keywords: Cc: marcelo@…, dcbw@…, mbletsas@…, carrano@…
Action Needed: Verified: yes
Deployments affected: Blocked By:
Blocking:

Description (last modified by jg) (diff)

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.

Change History

  Changed 7 years ago by jcardona

  • cc marcelo@…, dcbw@…, mbletsas@…, carrano@… added
  • owner changed from blizzard to rchokshi

  Changed 7 years ago by jg

  • milestone changed from Untriaged to BTest-3

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

  Changed 7 years ago by jcardona

  • owner changed from rchokshi to jcardona
  • status changed from new to assigned

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.

  Changed 7 years ago by jcardona

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

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

  Changed 6 years ago by jcardona

  • priority changed from normal to blocker
  • version set to Development build as of this date
  • milestone changed from BTest-3 to Update.1

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

  Changed 6 years ago by jcardona

  • status changed from closed to reopened
  • resolution deleted

  Changed 6 years ago by jcardona

  • owner changed from jcardona to ashish
  • status changed from reopened to new

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

follow-up: ↓ 10   Changed 6 years ago by 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.

in reply to: ↑ 9   Changed 6 years ago by jcardona

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

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.

  Changed 6 years ago by jcardona

  • status changed from closed to reopened
  • resolution deleted

  Changed 6 years ago by jg

  • description modified (diff)

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

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

  Changed 6 years ago by mbletsas

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

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

M.

Note: See TracTickets for help on using tickets.