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 _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
