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

[Dan Williams]

On Mon, 2009-11-30 at 11:21 -0800, Sam Leffler wrote:
> On Mon, Nov 30, 2009 at 10:23 AM, Dan Williams <dcbw at redhat.com>
> wrote:
>         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.
> 
> 
> That's fine but it appears your changes were to common code so affect
> all drivers and os's and instead of aging entries just toss
> everything.

Hmm, the patch doesn't age entries or anything, it simply doesn't
request another whole scan if scan results were delivered in the past 10
seconds.  There may be an issue here with broadcast scan vs. directed
scan depending on whether the driver returns filtered results, which we
can fix up I guess.  But in the end, if the driver returned some results
10 seconds ago, there's not much of a reason to suspect it's behavior on
the next scan will be dramatically different with the same set of inputs
to the scan command, or at least it shouldn't be.

 
>         
>         > 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).
>         
> 
> 
> Yes I saw it.  I didn't see changes like I suggested for separating
> scan from MLME ops.  I also think the scan args are incomplete but
> that's a separate discussion (and my fault for not following up).

I don't quite understand what you mean about "separating scan from MLME
ops"... can you explain a bit further?

The scan args are not complete because we focused on the most common
options and also because most drivers don't yet implement the more
exotic ones, and the supplicant doesn't have the facility to pass those
options through to the driver anyway.  But when that infrastructure is
present in the supplicant, the arguments can easily be added to the
D-Bus interface because it's a dict.  I had originally specced out a
bunch of different parameters for filtered scans, but that list was
reduced considerably since the rest weren't even implemented yet.

Dan