[PATCH] Avoid unnecessary triggering of rescans

[Dan Williams]

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?

Dan

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