wpa_supplicant: Issue with long scan times on startup.

[Ben Greear]

On 05/22/2013 01:07 AM, Jouni Malinen wrote:
> On Tue, May 21, 2013 at 08:09:31PM -0700, Ben Greear wrote:
>> When you have lots of stations, the initial scan time logic
>> goes a bit haywire, causing long delays before the initial scan
>> is attempted.
>>
>> The patch below works better for me:
>
>> diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
>> @@ -2420,9 +2420,9 @@ int wpa_supplicant_driver_init(struct wpa_supplicant *wpa_s)
>> -                       wpa_supplicant_req_scan(wpa_s, interface_count,
>> +                       wpa_supplicant_req_scan(wpa_s, interface_count % 3,
>>                                                  100000);
>>                  interface_count++;
>
>> Any interest in pushing something like this upstream?
>
> That's probably fine. When you go beyond tens of stations, all bets are
> off on scanning anyway ;-). I'd make that value a bit higher, though,
> since some concurrent cases are starting to show up with larger number
> of interfaces. Say, five would sound fine to use in upstream and I'd
> assume it wouldn't make much of difference for you either.

The logic that shares scan results helps a lot, and the kernel will reject
(EBUSY I think) duplicate scan attempts.  As long as supplicant backs off
in some way, I don't think the initial scan time that this patch modifies
matters too much.  I'm tempted to decrease it down to % 2, in fact...

The patch I put in recently to allow scan-on-channel when 1+ VIFS is associated is
also a big help in this case.  At least for ath9k, there is basically zero
overhead to scanning just on the working channel (we can continue processing
normal frames during the scan process).

Another reason why I don't like the initial timer is that we may
have 100 stations associated, and then we add the 101'st.  There is no
reason not to scan right away..or at least very quickly, since it will
be the only station scanning....

Thanks,
Ben


>
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com