[PATCH] don't re-scan on SELECT_NETWORK with recent scan results

[Dan Williams]

On Mon, 2009-11-30 at 09:19 -0800, Sam Leffler wrote:
> On Sun, Nov 29, 2009 at 3:37 PM, Dan Williams <dcbw at redhat.com> wrote:
>         It's pretty pointless to trigger a new scan when a control
>         interface
>         calls SELECT_NETWORK if the scan results are less than 10
>         seconds old.
>         This speeds up associations when the connection manager has
>         already
>         requested a scan to determine what BSS to connect to, and then
>         tells the
>         supplicant to select that BSS, which previously would trigger
>         yet
>         another scan a few seconds after the first one.
>         
> 
> 
> It's difficult for me to tell from the patch but in my experience you
> want to treat the scan results as a cache and age entries out and/or
> flush explicitly under certain conditions.  This appears to be
> something short of that.

Yes; at least on Linux the 802.11 stack will keep results around for
some specific period of time.  But that's only about 10 seconds or so.
I believe the supplicant throws results away when new results come in
(either unsolicited or from an explicit request).

> There's also the issue that this process may already take place below
> wpa_supplicant in which case you don't want it doing the same work.

Right, but the supplicant only uses it's own cache since it can't depend
on specific driver behavior; at least on Linux we've more or less
decided that the kernel and drivers should not be in the business of
doing anything other than simple timestamping of the scan results and
passing them up to userspace on request, within a period of about 10 -
15 seconds.  After that it's up to userspace to cache results since
userspace is where the caching policy should live.

> Related to this whole issue is that the d-bus api needs to provide
> better control over scanning and likely also split out scanning from
> MLME operations like associate.

Have you seen the new D-Bus API that Witold and I specced out (and he
implemented) over the summer and fall?  It's an attempt to  make the
dbus interface more flexible, and was posted for comments earlier this
year on the list (June 11, July 11, and Oct 17).  It includes quite a
lot of flags for scan requests (including SSID, channel, etc).

Dan