On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: > Dan Williams wrote: > > On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: > >> Howard Chu wrote: > >>> This is probably more related to the ath9k driver, but I wanted to start > >>> here > >>> in case anyone is familiar with it. I've been seeing this for the past > >>> couple > >>> months, and I just now rebuilt NM fresh from git and it's still happening: > >> > >> I seem to have ruled out the driver; doing a kill -9 on NetworkManager so > >> it > >> doesn't have the opportunity to tear down the connection on exit, shows > >> that > >> the wifi connection works perfectly once NetworkManager is gone. No > >> disassociation messages in dmesg, no pauses in ssh sessions, etc. > > > > Don't rule out the driver. Does the driver always return the currently > > associated AP in the scan list? If not, you might hit this. And the > > driver is being stupid, because of *course* the AP you're currently > > connected to should always be in the scan list, unless you're no longer > > connected to it. > > > > The code in NM grabs the SSID& BSSID on a 6 second timer, and tries to > > find that AP in the scan list. If it can't find it (because the driver > > didn't return that AP in the scan list) then it reports none. > > > > If that's your problem, it's a driver problem. > > How would I check this? Should it be obvious from "iwlist scan" ? That > returns > the current AP along with the other visible ones. > > Also, reviewing the comments in bug 291760, this problem is not just isolated > to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, > ipw2100, > rtl8187, and b43, across multiple kernel and driver revisions. As such it > seems unlikely to be the drivers' fault.
Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
