WLAN: Traps and Surprises

[Werner Almesberger]

Since quite a lot of WLAN problems have been reported, we decided to
start a more systematic search for them, and any usability exceptions
we may hit on the way.

The approach is to make tries in a controlled environment and to
work bottom-up, i.e., we begin with completely unprotected networks
and then work our way up to WEP and finally WPA.

The controlled environment means that we won't catch every freak
interoperability accident (e.g., bug #1250), but we'll at least be
able to establish a known to be good setup process, and thus in a
far better position to investigate other problems.

This effort is still very much in progress, but there are already a
few results that may be useful.


Unprotected, WEP, or WPA:

- ESSID must be either zero-length, or 2 bytes or longer
  Effect: iwconfig rejects the configuration request
  Reason: AR6k driver assumed old API
  Work-around: replace ESSIDs with length 1 with longer ESSIDs
  Status: fix is on its way through the build process

- ESSID must be 31 bytes or shorter
  Effect: iwconfig rejects the configuration request
  Reason: buffer overflow in kernel or AR6001 firmware
  Work-around: replace ESSIDs with length 32 with shorter ESSIDs
  Status: further analysis required

- WLAN setup through the Om2008 GUI doesn't work
  Effect: device does not obtain an IP address
  Reason: API incompatibility between ConnMan and DHCP
  Work-around: use command-line tools (iwconfig and udhcpc)
  Status: being fixed


If using WEP:

- Must set ESSID after WEP key
  Effect: ESSID is cleared
  Reason: setting the WEP key resets the ESSID
  Work-around: set WEP key first, then ESSID
  Status: design limitation, no action required

- Setting the WEP key as a string yields incompatible result
  Effect: iwconfig ... key s:password ... either fails or succeeds
    but traffic on top of 802.11 is rejected
  Reason: iwconfig sets the key to literally "password", and not the
    binary pattern (hash ?) almost everybody else uses. See also:
    http://www.powerdog.com/wepkey.cgi
  Work-around: only set the key in numeric form
  Status: design limitation, no action required

- Bad WEP key lingers and stays until traffic stops for a while
  Effect: traffic on top of 802.11 is rejected if an incorrect WEP
    key has been set, even if the key is changed on the device later
  Reason: new keys are apparently only considered after the device
    has been idle for about 30-80 seconds
  Work-around: stop all traffic, including DHCP, set the correct
    WEP key, wait at least one minute, then DHCP
  Status: further analysis required


We'll post updates as we progress.

- Werner