[PATCH] don't re-scan on SELECT_NETWORK with recent scan results
Sam Leffler
sleffler
Mon Nov 30 11:21:34 PST 2009
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
More information about the Hostap
mailing list