[PATCH] don't re-scan on SELECT_NETWORK with recent scan results
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap