[PATCH] Avoid unnecessary triggering of rescans

[Helmut Schaa]

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?

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).

> 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.

> 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).

Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa_supplicant_0.5.10.log.tar.bz2
Type: application/x-tbz
Size: 6538 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080227/25af9d01/attachment.bin