wpa_supplicant 0.7.3 slow to associate, 0.6.10 is ok

[Koen Beel]

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

Br,
Koen

>>
>> Dan