[RFC 0/5] nl80211: add support for g-scan

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

Android employs a Wifi-HAL layer in its wireless frame. It basically abstracts
dealing with netlink messages from the framework. For some features it employs
nl80211 vendor commands. The goal I set myself is to be able to have a generic
nl80211 Wifi-HAL implementation. One of the features currently requiring the
vendor commands is g-scan. We can only guess what the 'g' stands for ;-) This
series converts the vendor command api into common nl80211 api.

Before making an attempt to explain more about the g-scan functionality first
this. While I am still testing the driver implementation resulting in numerous
questions Dmitry send the email below to bring a related discussion to the
table..eh.. the linux-wireless list. This is probably a good thing as anyone
can dive in and share their thoughts.

On 16-11-2016 23:47, dimitrysh@google.com wrote:
> From 68a9d37a4c7e9dc7a90a6e922cdea52737a98d66 Mon Sep 17 00:00:00 2001
> From: Dmitry Shmidt <dimitrysh@google.com>
> Date: Wed, 16 Nov 2016 14:27:26 -0800
> Subject: [PATCH] RFC: Universal scan proposal
>
>   Currently we have sched scan with possibility of various
> intervals. We would like to extend it to support also
> different types of scan.

Extending would be an option, but replacing sched_scan by uscan does not
seem like a good idea although you are only redefining the driver api, but
it seems elaborate to map all user-space scans to the new uscan callback.

>   In case of powerful wlan CPU, all this functionality
> can be offloaded.
>   In general case FW processes additional scan requests
> and puts them into queue based on start time and interval.
> Once current request is fulfilled, FW adds it (if interval != 0)
> again to the queue with proper interval. If requests are
> overlapping, new request can be combined with either one before,
> or one after, assuming that requests are not mutually exclusive.
>   Combining requests is done by combining scan channels, ssids,
> bssids and types of scan result. Once combined request was fulfilled
> it will be reinserted as two (or three) different requests based on
> their type and interval.
>   Each request has attribute:
> Type: connectivity / location
> Report: none / batch / immediate

These probably need more explanation. The 'Type' attribute gives hint about
the high-level use-case, ie. (android) connectivity or location service. This
obviously should have a different behaviour in the driver/device so we need to
describe that behaviour.

>   Request may have priority and can be inserted into
> the head of the queue.
>   Types of scans:
> - Normal scan
> - Scheduled scan
> - Hotlist (BSSID scan)
> - Roaming
> - AutoJoin

Are these last two really scans? How should AutoJoin work dealing with the
connection state of wpa_supplicant and driver/device if establishing the
connection is entirely offloaded including eapol handshakes and key derivation.

Now getting back to this series, it adds basic support of g-scan (or GScan, or
gscan, or something completely different; suggestions are welcome). A basic
g-scan request consists of some common attributes and so-called buckets. Each
bucket represents a re-occurring scan request with a given interval and a set
of channels. The common attributes specify how much scans (m) should be stored
and how many BSS-es (n) should be kept per scan before an event is sent. The
other option is to specify a percentage at which an event is sent, where 100%
equals (m * n). It also specifies the base period, but we may drop that as it
is the gcd() of the individual buckets. A special case of bucket is the
exponential backoff bucket, which has a increasing interval.

Whether this type of scan offload is a good addition depends on the high-level
use-case(s). It would help this discussion greatly to know those use-case(s).
A current hurdle for me is that the device stores m scans so a BSS could end up
in the result of either of them. However, cfg80211 stores BSS-es uniquely with
latest scan information. Does user-space need results per scan or is flat BSS
storage fine.

Anyway, here is some more fuel to the discussion.

Regards,
Arend

Changes:
 V2
  - remove pr_err() statement from nl80211.c
  - get rid of #if 0 code.
  - reordered patches resolving compilation issue.

Arend van Spriel (5):
  nl80211: allow reporting RTT information in scan results
  nl80211: add reporting of gscan capabilities
  nl80211: rename some notification functions
  nl80211: add support for gscan
  nl80211: add driver api for gscan notifications

 include/net/cfg80211.h       | 166 +++++++++++++++-
 include/uapi/linux/nl80211.h | 212 +++++++++++++++++++++
 net/wireless/core.c          |  33 ++++
 net/wireless/core.h          |   6 +
 net/wireless/nl80211.c       | 440 +++++++++++++++++++++++++++++++++++++++++--
 net/wireless/nl80211.h       |   4 +-
 net/wireless/rdev-ops.h      |  25 +++
 net/wireless/scan.c          |  95 +++++++++-
 net/wireless/trace.h         |  19 ++
 9 files changed, 984 insertions(+), 16 deletions(-)

--
1.9.1