Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

On 16-12-2016 11:02, Johannes Berg wrote:
> 
>> Not sure what is meant by "through the buckets".
> 
> TBH, I was handwaving because I don't understand this part of gscan
> well :-)
> 
>> Referring to your
>> remark/question in the "Unversal scan proposal" thread:
>>
>> """
>> I'm much more worried about the "bucket reporting" since that doesn't
>> fit into the current full BSS reporting model at all. What's your
>> suggestion for this?
>> """
>>
>> So this is exactly the dilemma I considered so I decided to stick
>> with the full BSS reporting model for gscan as well merely to get it
>> discussed so glad you brought it up ;-).
> 
> Heh.
> 
> Ok, so I missed that. Somehow I thought hidden in the buckets was a
> partial reporting :-)
> 
>> The problem here is that gscan is a vehicle that serves a number of
>> use-cases. So ignoring hotlists, ePNO, etc. the gscan configuration
>> still hold several notification types:
>>
>> - report after completing M scans capturing N best APs or a
>>   percentage of (M * N).
>> - report after completing a scan include a specific bucket.
>> - report full scan results.
>>
>> The first two notification trigger retrieval of gscan results which
>> are historic, ie. partial scan results for max M scans.
>>
>> As said earlier the universal scan proposal has some similarities to
>> gscan. Guess you share that as you are using the term "bucket
>> reporting" in that discussion ;-). The historic results are needed
>> for location (if I am not mistaken) so the full BSS reporting model
>> does not fit that. Question is what particular attribute in the
>> historic results is needed for location (suspecting only rssi and
>> possibly the timestamp, but would like to see that confirmed). I was
>> thinking about have historic storage in cfg80211 so we do not need a
>> per-driver solution.
> 
> Ok, now I'm starting to understand this better, I guess.
> 
> As far as I can tell from our code, for cached results we're reporting
> the following data:
> 
>  * some flags
>  * a scan ID
>  * and for each AP:
>    * RSSI
>    * timestamp
>    * channel
>    * BSSID
>    * SSID (which internally we even have a separate table for and each
>            AP just has an index to it, to save memory I guess)
>    * beacon period
>    * capability field
> 
> No IEs and similar things like differentiating probe response/beacon,
> so we can't use the full reporting for this.
> 
> I have no problem introducing a common storage for this, if necessary
> with some fields/nl attributes being optional, but I suspect this is
> actually a necessary part of gscan, otherwise you're not able to report
> all the necessary data?

If you just look at the gscan api in wifihal then yes. I was just
wondering whether "all the necessary data" really comprises all these
from a use-case perspective. As an example the api also has rtt fields,
but both brcm and intel solutions do not report that.

Regards,
Arend