WLAN: towards a solution for the roaming freeze

Werner Almesberger werner at openmoko.org
Thu Jan 22 23:02:13 CET 2009


I wrote:
> I'm now running a longer experiment that should turn up more data.

This time I got 999 hops:
http://people.openmoko.org/werner/wlan-freeze/6.bz2

Of them, 44 caused an extended interruption of communication. 24 of
these problems were caused by a firmware crash. Of the remaining 20
problems, only one needed a reset while the others went away after
iwconfig, iwlist scan, or just waiting. (Again, this may just mean
that the WLAN module needs a bit more time to recover.)

I looked for how the channel change is related to what the WLAN
module does. It seems that the departing channel has only a small
effect on what happens:
http://people.openmoko.org/werner/wlan-freeze/6ch-FROM.png
(x-axis is the channel number, y-axis the percentage of events.)

If we change to one of the channels 5-8, further problems seem to
be particularly likely:
http://people.openmoko.org/werner/wlan-freeze/6ch-TO.png

There is a very strong correlation between channel distance and
future trouble:
http://people.openmoko.org/werner/wlan-freeze/6ch-DIST.png
(x-axis is the distance between the channels.)

Oddly enough, if we change across two channels, we're even more
likely to miss the change on the first try than when changing to an
adjacent channel.

This points clearly to frequency leakage as a key factor in all the
issues, be they just a miss on the first association (which isn't
necessarily a problem) or a firmware crash (which very much is).

Frequency leakage is a complication inherent to the design of
802.11abg, so we're not seeing anything new here. The number of
misses seems high, though. And of course none of this gives the
firmware an excuse for crashing.

- Werner



More information about the devel mailing list