[PATCH] Avoid unnecessary triggering of rescans

[Sam Leffler]

Dan Williams wrote:
> On Fri, 2008-03-07 at 09:04 +0200, Jouni Malinen wrote:
>   
>> On Wed, Feb 27, 2008 at 05:53:52PM +0100, Helmut Schaa wrote:
>>
>>     
>>> The setup here is a bit complex, I have multiple hidden APs with the same 
>>> ESSID around.
>>>
>>> Once wpa_supplicant gets the scan-results (not being the scan initiator) it 
>>> tries to find a suitable AP. If it finds the one you're currently associated 
>>> with it drops the message "Already associated..." and does not do anything 
>>> else.
>>>       
>> That is the expected behavior for processing unsolicited scan results.
>>
>>     
>>> Otherwise it starts a new scan. Once it starts a scan for a specific ESSID it 
>>> will get the currently associated AP but in my case there are even more APs 
>>> which match the ESSID and wpa_supplicant will start associating with the 
>>> first matching AP.
>>>       
>> This is also expected. If the scan results do not include the current
>> AP, wpa_supplicant assumes that the AP is not available anymore and
>> tries to find another AP to use. I would like to make sure all drivers
>> return the currently associated AP in scan results always regardless of
>> the scan type. This information is needed, e.g., for WPA security
>> validation.
>>     
>
> _Definitely_.  This should be required of all drivers.
>   

Actually I very much disagree with this requirement.  Scan results 
should reflect the actual set of AP's found while scanning and not 
include arbitrarily defined results.  What should be done instead is to 
treat the scan results as a cache and time out entries.  Doing this 
correctly will cause the current AP to be included w/o polluting the 
results.

    Sam
> dan
>
>   
>>> Perhaps it would be even better to do nothing when scan-results come in and 
>>> wpa_supplicant is not in state WPA_SCANNING.
>>>       
>> The goal in the current design is to allow changing the APs based on
>> background scans if a better AP becomes available. As such, I do not
>> want to change this part of the design.
>>
>> In general, I would like to get the driver changed to return the current
>> BSS (including its SSID even if the AP does not broadcast it) in scan
>> results. If for some reason that is not possible, the driver wrapper
>> should somehow notify core supplicant code (e.g., a capability flag)
>> that this is the case and allow wpa_supplicant to ignore
>> current-AP-missing-from-results case when such a driver is used (and not
>> to reduce functionality with other drivers that work more properly).
>>
>>     
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
>
>