[PATCH] Avoid unnecessary triggering of rescans
hschaa at suse.de
Wed Feb 27 09:18:30 EST 2008
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
That would do the trick too, yes (if the driver reports the currently
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6538 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080227/25af9d01/attachment.bin
More information about the HostAP