GNOME Bugzilla – Bug 607457
reconnects to previous AP without even scanning for its presence
Last modified: 2010-01-21 21:35:04 UTC
Running Ubuntu 9.10 on a Dell Mini 9 with the broadcom STA driver (BCM4312), NM always immediately tries to reconnect to my previously associated wifi network when I come back from suspend or when I re-enable wifi (by right-clicking the nm-applet). It seems it doesn't scan to check if the network is *actually* there before trying to associate, which is a waste of time when I'm in the presence of another known network I would like to associate with. The only way to work around this is to manually ask nm to disconnect from the (nonexistent) AP it tries to connect with initially.
This is a problem in the proprietary, binary broadcom STA driver. I'd suggest using the standard kernel b43 driver if you can, otherwise you'll have to wait for broadcom to update their driver. This problem was fixed in the upstream kernel for the open-source drivers a long time ago, but since you're using the proprietary Broadcom driver you don't get that fix. For more information, see: http://blogs.gnome.org/dcbw/2009/02/26/suspendresume-vs-networkmanager/ The short story is that there's a bug in the broadcom driver where it doesn't time out APs accurately across suspend/resume, and so on resume the driver sends NM the list of APs frmo before you suspended.
I see, I suspected the proprietary driver to be at fault, but wondered if there was anything NM could do (I wouldn't be using the proprietary driver if the open source one actually worked :( and I can't go around asking all my netbook-wielding friends to fork cash over to replace their "working" bundled wifi chip (wtf is wrong with all laptops coming with those broadcom chips these days?). That blog post mentions (from what I understand) ageing the jiffies. Which I don't totally understand why, if this is indeed done, it doesn't work. And if it doesn't work for some reason... Can't you force a scan on resume for drivers that have nonsense jiffies? Failing that, is there an actual place (except trying to call Broadcom and get laughed at) where I can bug them? Thanks for your answer!
(In reply to comment #2) > I see, I suspected the proprietary driver to be at fault, but wondered if there > was anything NM could do (I wouldn't be using the proprietary driver if the > open source one actually worked :( and I can't go around asking all my > netbook-wielding friends to fork cash over to replace their "working" bundled > wifi chip (wtf is wrong with all laptops coming with those broadcom chips these > days?). > > That blog post mentions (from what I understand) ageing the jiffies. Which I > don't totally understand why, if this is indeed done, it doesn't work. And if jiffies is an internal kernel timer. The driver itself keeps a list of the APs it has scanned for a certain length of time. If the driver is incorrectly written, then it will not track *total* time, but only uptime, before dropping old scan list entries. Total time is wall-clock time; if you have suspended for an hour, then of /course/ those scan list entries should be immediately dropped on resume. But the incorrect drivers only track uptime (time the machine itself has been running) and thus when you come back from suspend the driver doesn't think any time has passed. > it doesn't work for some reason... Can't you force a scan on resume for drivers > that have nonsense jiffies? Jiffies are internal to the kernel. The mechanisms for detecting when APs were last scanned (see "last_beacon" in the output of 'iwlist wlan0 scan') *also* rely on jiffies and thus are calculated incorrectly here in the bad drivers. So no, the driver needs to be fixed. > Failing that, is there an actual place (except trying to call Broadcom and get > laughed at) where I can bug them? Not that I know of; you can try filing a bug in Launchpad because the Ubuntu kernel team does talk to Broadcom sometimes. But I guess buy Intel or Atheros next time...? They actually care about Linux.