[PATCH] Avoid unnecessary triggering of rescans

[Sam Leffler]

Dan Williams wrote:
> On Fri, 2008-03-07 at 10:11 -0800, Sam Leffler wrote:
>   
>> 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.
>>     
>
> Cached scan results + timeout is what happens in every driver I touch.
> Orinoco, airo, libertas were done by me, and ipw2x00 and others work
> this way too.
>
> However, if the card is associated with an access point, _why_ would it
> not always be reported in the scan results???  It's not being
> "arbitrarily defined", because the card is still associated with the AP,
> and thus the AP definitely exists, or the card should have issued a
> disconnection event.  If the firmware isn't including the associated AP
> in it's scan result list, the firmware sucks rocks.
>   

If you do something like a background scan you may find on return to the 
home channel that your ap has moved but you may not recognize this until 
after you have dispatched the scan results.  You are mixing a policy 
(include the current associated AP even if it was not seen in a scan) 
with a mechanism; this will get you in trouble.

The real problem is that wpa_supplicant has a model for state changes 
and scanning that is designed to work with a wide variety of drivers.   
To do this it makes certain requirements of the underlying code to 
compensate.

    Sam