wpa_supplicant 0.7.3 slow to associate, 0.6.10 is ok

[Dan Williams]

On Mon, 2012-08-20 at 12:40 +0200, Koen Beel wrote:
> >> The logs indicate the driver is clearly refusing scan requests because
> >> it is "busy" doing something else, probably already scanning.  But since
> >> WEXT has no facility (and never will, since it's dead) to indicate any
> >> of it's internal status operations, the supplicant never knows that.
> >> Instead of hacking the supplicant up to work around deprecated kernel
> >> driver APIs, it's fairly simple to modify the driver to handle this case
> >> better, by not returning EBUSY to the supplicant's scan request, but
> >> returning success instead (since a scan request is ongoing already, why
> >> not? the supplicant will get the results when it's done anyway).
> >
> > Ok, I'll give that a try.
> > Looks like the driver is returning EAGAIN in several cases in the
> > SIOCSIWSCAN ioctl. I'll change that to return success and see what we
> > get.
> >
> > Br
> > Koen
> 
> Tried that, but does not improve association time at all.
> The warning messages are gone though.
> 
> >>
> >> Next step would be to cache scan results in the driver, but you might be
> >> able to get away without that for now.  Again, we've fixed all the
> >> in-kernel drivers to do this, but since your driver is out-of-tree, it
> >> hasn't been.
> 
> Figured out that the scan results are already cached in the driver in
> one way or another.
> 
> When taking wpa_supplicant 0.6.10 vs. 0.7.3 we see that this caching
> is more or less explaining the difference in association time.
> Scenario:
> - driver is loaded and has done a scan at least once (cached results).
> - when 0.6.10 is started, first the scan results are read from the
> driver (cached). Only if scan results not available or not containing
> the needed info, a scan is triggered.
> - when 0.7.3 is started, first a scan is triggered. Only after that
> the scan results are read form the driver (new).
> 
> So basically, it looks like wpa_supplicant 0.7.3 does not use the
> cached results at all.
> It could be useful to understand why this is like that.
> 
> However, taking all this into account it means that this difference
> between 0.6.10 and 0.7.3 is not relevant for our primary use case. In
> our product the initial association time is most important, not the
> re-association time (using cached scan results, etc...).
> 
> So we will looks into other options to improve the association speed on 0.7.3.
> One thing we are looking at is to limit the frequency band used.

WEXT can't limit on frequency band, I think it can only limit on
channels, and not many at that.  Plus no driver actually ever used that
functionality, it was really only implemented eventually with nl80211.

The commit which removed that "use existing scan results on startup" is
24f7694062f64dc9c549fbe8c348b0262bdb90e6 .  That functionality
apparently had problems with certain drivers, plus it depends on your
device having done a generic scan before the supplicant has started,
which is certainly not a given.  Unless the driver ages and expires the
scan results (which not all drivers correctly did long ago, nor was
there a WEXT mechanism to control how long they should be cached) you
may get quite stale results which can effectively increase your
connection time.

Honestly though, these days most well-written drivers should be able to
scan the 2.4GHz channels in well under 3 seconds using active scans.
But even with passive scans (defaulting to say ~120ms dwell time),
scanning all 13 channels should be well under 3 seconds too.  Obviously
that increases a lot with the 5GHz band due to the larger number of
channels.

Dan