[PATCH] Avoid unnecessary triggering of rescans

[Sam Leffler]

Dan Williams wrote:
> On Sun, 2008-03-09 at 10:48 -0700, Sam Leffler wrote:
>   
>> Dan Williams wrote:
>>     
>>> On Fri, 2008-03-07 at 15:28 -0800, Sam Leffler wrote:
>>>   
>>>       
>>>> 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.
>>>>     
>>>>         
>>> True; I do handle this in NM by never removing the associated BSSID from
>>> the internal NM scan list, but of course wpa_supplicant has it's own
>>> scan list.  Are you suggesting that the policy of never removing the
>>> associated BSSID should be in the supplicant and not the driver?
>>>   
>>>       
>> What you mean by "driver" is unclear to me.  In general you want any 
>> caching to be done where you have the most info to intelligently manage 
>> it.  I'm not familiar with NM but for me the right place appears to be 
>> wpa_supplicant.
>>     
>
> Instead of driver read "kernel", which includes both the stack and the
> driver.  Since most of the drivers in Linux using mac80211 are actually
> thin shims around mac80211, they certainly shouldn't be doing any scan
> result caching.
>   

What about all the other "drivers" inside wpa_supplicant and the 
in-kernel drivers that linux users still depend on?  Or are they not 
relevant to NM and/or this discussion?

>   
>> In my environment (freebsd) wpa_supplicant talks to an 802.11 layer 
>> shared by _all_ wireless drivers and that layer can be instructed to 
>> cache scan results or flush the cache prior to a scan.  The cache gives 
>>     
>
> Ok; sounds kind of like what's done in Linux right now, but userspace
> cannot flush the cache.  I personally think that's wrong, because it
> allows one userspace app to affect the scan result policy for all other
> userspace apps.  If the userspace app doesn't want certain entries in
> the scan cache, it should simply ignore any returned BSSes with a
> timestamp of < now - 5 or something.  No good reason to flush the cache
> and screw all the other apps (there can certainly be more than one
> consumer of scan results of course).
>   

Manipulation of the in-kernel scan cache is a privileged operation.  It 
is frequently the case that only applications know the when a flush is 
appropriate.  Regardless, if you want apps to control this then they 
should manage it--which is how we got here in the first place.

>   
>> the behaviour wpa_supplicant (currently) wants but I think this setup is 
>> suboptimal because the eviction policy lacks information that only 
>> wpa_supplicant has.  What this really boils down to is that you need to 
>> decide where the scan cache is maintained.  wpa_supplicant's current 
>> design forces certain policy into the code below it.  I still need a 
>>     
>
> True.  Jouni, would you accept patches that cache scan results in the
> supplicant for a while similar to what currently happens in some
> drivers?  Proposed policy:
>
> 1) Keep a per-device scan cache to hold wpa_s objects
>
> 2) Keep the BSS that the supplicant is associated with in the scan list
> until disassociation
>
> 3) Keep scan results around for ~ 15 seconds before culling them;
> perhaps this threshold value could be a config option
>
> Thoughts?  This would include changes to
> wpa_supplicant_get_scan_results() and
> wpa_supplicant_get_scan_results_old() to not simply free the old scan
> list, but to merge scan results, removing ones older than the threshold,
> adding new ones, and updating the timestamp of ones found again.
>   

wpa_supplicant already has something like this by way of it's 
blacklist.  The issue is that you need the whole MLME state machine to 
be integrated so things like deauth and beacon miss handling work 
consistently.

>   
>> scan cache for when wpa_supplicant is not being used (we do not require 
>> wpa_supplicant to operate in open auth environments) which is why I 
>> provide a fair amount of flexibility.  This also ignores the question of 
>> how to manage multiple wireless devices (e.g. do they share a common cache).
>>     
>
> A common, system-wide cache isn't the right solution, because different
> devices have different characteristics.  For example, if you have an
> 802.11b capable card with a crappy antenna (Cisco Aironet 350), it does
> no good to advertise an AP found from an internal card that's got much
> better antennas, because you'll never ever be able to connect to that AP
> using the Airo card until the airo card see it in it's own scan results.
>   

I think your focus is too narrow.  Let's just say that if you want to 
build a user-space service to manage scanning (and a scan cache) it is 
necessary to think about multi-radio applications and different 
operating modes than station/infrastructure.

    Sam

> Dan
>
>   
>>     Sam
>>     
>>>   
>>>       
>>>> 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
>>>>
>>>>     
>>>>         
>>>   
>>>       
>
>
>