[connectivity-service] Extend the connectivity-api for WiFi scanning
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
indicator-network (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
I am currently trying to build a WiFi scanner app for Ubuntu Touch. Since Click apps are confined and have no root rights, all other approaches failed. I hereby propose to expose the needed information and API calls through the connectivity-api.
The minimum amount of information needed is:
- A list of all broadcasting stations (BSS/IBSS) in range
- Broadcast station MAC address
- SSID (may be emtpy)
- Center frequency or channel (the one can be converted into the other)
- Signal strength
- Available authentication and encryption schemes
- Timestamp when the station was last seen
This is basically the same information as encapsulated in an android.
Optional, but "nice to have" information would be:
- The contents of the "Capability Info" field of the beacon frame.
- Supported data rates, so one can distinguish between 802.11b/g/n/ac networks. This information is encoded in the "Rates" and ""Supported MCS Set" fields of the beacon frame.
- The contents of the "HT Capability Info" field (if present) of the beacon frame.
This optional information is already recorded by the kernel and is e.g. decoded/displayed by a call to `iw dev wlan0 scan`.
Since the network management service has to monitor its surroundings anyways, e.g. to detect and connect to an already known network or to switch to a better access point during movement, the information should be readily available. A single `scanResults()` call returning a list of broadcast station objects should therefore already be enough.
I propose the following additional API features:
- A method to register a callback function which is called after every successful scan. This frees the application from polling the API, may save power and the app can process new information instantly.
- A method to set the scan interval within a pre-defined range. The network management service may decide to adapt its scan interval to the current situation to save power, e.g. a longer interval when not currently connected and a short one when connected. A scanner app may require a short, constant interval.
summary: |
- Extend the connectivity-api for WiFi scanning + [connectivity-service] Extend the connectivity-api for WiFi scanning |
no longer affects: | connectivity-api |
Changed in indicator-network (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
I want to add the following paragraph about security/privacy:
A hostile app may calculate the location of a user from the list of access points in range, and because of the short-range nature of WiFi this location will be quite accurate. I therefore propose that the first call to `scanResults()` triggers a system popup informing the user about possible privacy implications and asking for permission.