Re: Configurable scan dwell time?

[Ben Greear <greearb@candelatech.com>]

On 11/05/2015 08:06 AM, Johannes Berg wrote:
> On Thu, 2015-11-05 at 08:01 -0800, Ben Greear wrote:
>
>> My issue is that APs can be set to beacon at longer beacon times, and
>> then passive scanning at ~110ms intervals is not going to find the APs
>> very often (and with bad luck, technically it could *never* find the AP
>> due to scanning at unlucky periodic intervals).
>
> Which is probably why hardly anyone ever uses longer beacon intervals
> (also the added latency with powersave, of course)
>
>> So, when I know that I am doing passive scan, I would like the option
>> to set the dwell time larger.
>>
>> And, for active scanning, maybe 33ms is a lot longer that is actually
>> needed?
>
> There are some (WFA?) requirements to answer within 30ms, but not
> faster, so I think that's the reason for this value.

An AP could (and in my experience, does) answer probes much faster.

(With ath9k and ath10k AP, I see probe response within 1ms in a sniff I just did).

So, doing active scans you could *often* do an entire spectrum
scan 10 times faster than what we see today.

A supplicant could request a fast time, and then if that didn't find anything,
the next scan could be slower as needed.

>> I read through some of your comments from before.  I think we could
>> treat this as a hint to the driver, and it could ignore it as needed.
>>
>> Firmware implementations I'm aware of are already limited in a million
>> different ways, and of course if someone cared, they could propagate
>> the dwell time into the firmware if they cared.
>>
>
> The thing though is that there are now use cases in the standard(s)
> that want/require doing this. So just adding it as a hint will run the
> risk of userspace (like wpa_s) using this "hint" for implementing newer
> spec functionality, testing on ath9k and hwsim and declaring that it
> works :-) And then we're stuck with this feature being used/advertised
> on older devices where it doesn't actually work.

Scanning is already best effort.  Someone implementing this new hint
can just be aware of the limitations.  If nothing else, start a scan on
a known number of channels (or single channel), see how long it takes..then you know if the
driver is ignoring your hint or not.

> Now, having those standard use cases is actually a good argument *for*
> adding them in the standard API, but I think we need to be more careful
> around these issues - perhaps having drivers indicate that they support
> it, maybe even with valid ranges, etc.

I think that is vastly over-engineering the problem, but truth is, it
can always be added later if there is an actual need for that knowledge.

Thanks,
Ben

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