<div class="gmail_quote">On Mon, Nov 30, 2009 at 10:23 AM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, 2009-11-30 at 09:19 -0800, Sam Leffler wrote:<br>
> On Sun, Nov 29, 2009 at 3:37 PM, Dan Williams <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote:<br>
> It's pretty pointless to trigger a new scan when a control<br>
> interface<br>
> calls SELECT_NETWORK if the scan results are less than 10<br>
> seconds old.<br>
> This speeds up associations when the connection manager has<br>
> already<br>
> requested a scan to determine what BSS to connect to, and then<br>
> tells the<br>
> supplicant to select that BSS, which previously would trigger<br>
> yet<br>
> another scan a few seconds after the first one.<br>
><br>
><br>
><br>
> It's difficult for me to tell from the patch but in my experience you<br>
> want to treat the scan results as a cache and age entries out and/or<br>
> flush explicitly under certain conditions. This appears to be<br>
> something short of that.<br>
<br>
</div>Yes; at least on Linux the 802.11 stack will keep results around for<br>
some specific period of time. But that's only about 10 seconds or so.<br>
I believe the supplicant throws results away when new results come in<br>
(either unsolicited or from an explicit request).<br>
<div class="im"><br>
> There's also the issue that this process may already take place below<br>
> wpa_supplicant in which case you don't want it doing the same work.<br>
<br>
</div>Right, but the supplicant only uses it's own cache since it can't depend<br>
on specific driver behavior; at least on Linux we've more or less<br>
decided that the kernel and drivers should not be in the business of<br>
doing anything other than simple timestamping of the scan results and<br>
passing them up to userspace on request, within a period of about 10 -<br>
15 seconds. After that it's up to userspace to cache results since<br>
userspace is where the caching policy should live.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Related to this whole issue is that the d-bus api needs to provide<br>
> better control over scanning and likely also split out scanning from<br>
> MLME operations like associate.<br>
<br>
</div>Have you seen the new D-Bus API that Witold and I specced out (and he<br>
implemented) over the summer and fall? It's an attempt to make the<br>
dbus interface more flexible, and was posted for comments earlier this<br>
year on the list (June 11, July 11, and Oct 17). It includes quite a<br>
lot of flags for scan requests (including SSID, channel, etc).<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div>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).</div>
<div><br></div><div>-Sam</div><div> </div></div>