Re: Configurable scan dwell time?

[Johannes Berg <johannes@sipsolutions.net>]

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.

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

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.

johannes