Re: periodic_update(): Roamed ...

[Dan Williams <dcbw redhat com>]

                    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