Red Hat Bugzilla – Bug 138882
NetworkManager unusable with atmel_cs
Last modified: 2007-11-30 17:10:54 EST
Every time NetworkManager does a scan, the network drops. See upstream bug: http://bugme.osdl.org/show_bug.cgi?id=3338 Should there be a blacklist for such badly behaved drivers?
Hmm, I've got an atmel CS card (Belkin F5D6020) that seems to work alright... I'll have to test it more.
However, be aware that no network traffic usually flows out when the card is scanning, that's expected and a limitation of most cards. Therefore we try not to scan so often...
I understand that. It's only more visible with the atmel_cs, you can see the netstatus applet go to its "!" state, and traffic stopping for the best part of 2 seconds. On my laptop with an ipw2200 card, netstatus doesn't even have time to switch to a different icon.
I did back the scan interval off to 20s (from 10s) but that of course doesn't help when you're _in_ a scan. Cards usually stay on a particular channel for a certain period of time so they can intercept the beacons from the APs, and in the case of the atmel driver it may be longer. AFAIK the default for PrismII cards (like Netgear MA111) using the wlan-ng driver is min=200ms max=250ms for each channel for scanning, I don't know what other cards' intervals are. For the # of channels that the card has to support (up to 14 since AFAIK atmel_cs doesn't support a or g modes) multiplied by 200ms you of course get a couple second timeout. I'm not quite sure why other cards cope with this better... Atheros cards seem to freeze up traffic during the scan too, but Cisco and prism54 seem to handle scanning + traffic better.
Bastien, Does it seem to be any better with newer NetworkManager? I've introduced a backoff algorithm that does scanning later and later (max 60s interval though) if the list of networks doesn't really change on each scan. Drops back to 20s when the list changes.
Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.