Re: [PATCH] RFC: Universal scan proposal

[Dmitry Shmidt <dimitrysh@google.com>]

On Thu, Jan 5, 2017 at 3:46 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> If we go with approach to use parameters and let FW or MAC80211
>> layer to decide what type of scan to do,
>
> At that point though, is it even meaningful to ask "what type of scan
> is this"? Or put another way - what does "scan type" even mean?

Probably not - if we focus on actions and results then type of
scan is meaningless - at the end it is scan + after actions.

>> then in general the only
>> difference between different types of scan is what to do with result:
>> - Normal scan: ssid list, channel list, dwell params, etc...
>> - Sched scan: ssid list, channel list, interval
>> - BSSID scan: bssid list, channel list, interval
>> Action: Report when suitable results are found (in case of Normal
>> scan it will be at the end of scan)
>>
>> - Roaming / Autojoin: ssid list, channel list, interval
>> Action: Connect when suitable results are found
>>
>> - History scan: bssid list, channel list, interval
>> Action: Report when buffer is full / almost full
>
> Exactly. But the type of action is something set by the entity that
> triggered the scan, right? normal and roam would be equivalent anyway,
> no? wpa_supplicant would make a decision to connect - after the results
> are coming in.

> Oh, then again, maybe you're thinking of full-MAC devices - does a
> roam/autojoin scan really already *imply* a new connection? And if so,
> do we have to do it that way, or can we remove that type of action and
> make a connection decision in higher layers, so it's really the same as
> "report when suitable results are found"?

We need to consider case when FW may do some actions like connection
during roaming/autojoin.

>> So we can literally distinguish scan types by final action.
>
> Actually I think I'm just misinterpreting your wording - you mean that
> we can use the different final actions for the different scan types,
> not that we should actually say - in driver/firmware/... - "this is a
> history scan because the action is to report buffer full", right?

It depends how we want to make it flexible. For example we
may allow to FW to report even usual scan results not one by one
but as a chunk.

>> And for History scan we need new get_scan_results() command.
>>
>> Does it sound reasonable?
>
> I think it does.
>
> There's a bit more complication wrt. the level of detail in results
> though - sometimes the result may include all IEs (normal/sched scan),
> sometimes it may not ("history scan") - are we sure we really only need
> one new get_scan_results()?

Maybe not - it is possible I missed something. Also looking at our
conversation I think we should consider separate command pair
for history scan.

> johannes