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

[Sam Leffler]

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.


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

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20091130/a739e002/attachment.htm