[PATCH] Avoid unnecessary triggering of rescans

[Dan Williams]

On Wed, 2008-02-27 at 15:18 +0100, Helmut Schaa wrote:
> Hi,
> 
> I'm resending this mail as the attachment was too large in the first try.
> 
> Am Dienstag, 26. Februar 2008 03:57:35 schrieb Jouni Malinen:
> > On Mon, Feb 25, 2008 at 11:21:25AM +0100, Helmut Schaa wrote:
> > > Initiating a scan (with iwlist for example) while connected to an hidden
> > > AP results (dependend on the driver) in wpa_supplicant repeatedly
> > > triggering rescans every few seconds.
> > >
> > > This happens because of wpa_supplicant getting the SIOCGIWSCAN from
> > > iwlwifi when the scan is finished. wpa_supplicant handles the scan
> > > results and triggers a new scan due to the currently connected Essid not
> > > showing up in the list (as it is not broadcasted).
> >
> > Would it be possible to get a debug log showing this behavior? I would
> > be especially interested in this with the latest version (0.5.10 or
> > 0.6.3) and timestamps in the log (-ddt on command line).
> 
> Using 0.5.10 there is no endless scan-loop anymore. Now wpa_supplicant only 
> triggers one more scan until it finds the hidden AP and reassociates to it. 
> But the reassociation here is not necessary too :)
> 
> Nevertheless I've attached the output.
> 
> At line 221 wpa_supplicant gets the scan results and afterwards triggers its 
> own scan followed by the reassociation.
> 
> > > Since iwlwifi mostly needs more then three seconds for scanning
> > > wpa_supplicant will then hit the scan timeout (which is three seconds)
> > > and will again initiate a new scan.
> >
> > This part should work much better with the current version
> > (0.5.10/0.6.3) of wpa_supplicant. I added some code to change the
> > timeout to 30 seconds if the driver is detected to support SIOCGIWSCAN
> > events. This resolved number of stability issues with madwifi and I
> > would expect that to help in this particular case, too.
> 
> Yes, it's better now as I wrote above, but not perfect :)
> 
> > > The patch changes the behavior to only initiate a rescan if
> > > wpa_supplicant is in state WPA_SCANNING.
> >
> > I'm not sure I would like to do this or well, I'm too lazy to figure out
> > whether there could be any case where this would not be desirable.. ;-)
> 
> Is there any reason why wpa_supplicant should process SIOCGIWSCAN (in case of 
> wext) at all if the scan was not initiated by wpa_supplicant?

There's no real point in wasting free scan results if something else
requests a scan...

> If you are connected to an AP and start a scan using iwlist it's a bit 
> annoying to see wpa_supplicant either triggering a lot of scans (0.5.8) or 
> starting a reassociation (0.5.10).

That's odd; why should the supplicant even bother reassociating, or
triggering scans if scan results just come in without a request?
Doesn't it just say something like "Already associated with selected AP"
and do nothing?  That's what I usually see.

> > Does the driver include the BSS in scan results? I would hope that at
> > least the BSSID is included even if the network is hidden (if not, the
> > driver should be fixed..). 
> 
> The currently associated AP is not in the scan results at all :(
> So I guess the driver needs a fix.

Yeah, your driver sucks and needs fixing :)  If the driver/card can't
handle specific SSID scans through SIOCSIWSCAN and the resulting probe
responses correctly, there's something wrong in the driver that you need
to fix.  Your driver should work correctly with ap_scan=1 and
scan_ssid=1.

I'd also argue that the driver should _always_ include the BSS it's
associated to in the scan results, because until the firmware
disassociates or drops the connection, you know the BSS is there.  That
would fix these sorts of issues with hidden SSIDs while connected too.

> > A better fix would likely be to change the
> > network selection process to allow this kind of case to select the
> > network even if there is no SSID match as long as the BSSID in scan
> > results matches with the BSSID that the client is currently associated
> > with.
> 
> That would do the trick too, yes (if the driver reports the currently 
> associated BSSID).

Hmm, how does that play with multi-SSID BSSes?  Lots of Cisco APs allow
you to have a hidden SSID and a broadcast SSID on the same BSSID, with
different security capabilities.  You'd have to ensure that the match
would _also_ match the security capabilities of the BSS in the scan
results to what is currently enabled.

Dan