[Touch-packages] [Bug 1415098] Re: [connectivity-service] Extend the connectivity-api for WiFi scanning
** Changed in: indicator-network (Ubuntu) Status: New = Triaged ** Changed in: indicator-network (Ubuntu) Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-network in Ubuntu. https://bugs.launchpad.net/bugs/1415098 Title: [connectivity-service] Extend the connectivity-api for WiFi scanning Status in indicator-network package in Ubuntu: Triaged 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.net.wifi.ScanResult object on 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1415098/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1415098] Re: [connectivity-service] Extend the connectivity-api for WiFi scanning
** Summary changed: - Extend the connectivity-api for WiFi scanning + [connectivity-service] Extend the connectivity-api for WiFi scanning ** Also affects: indicator-network (Ubuntu) Importance: Undecided Status: New ** No longer affects: connectivity-api -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-network in Ubuntu. https://bugs.launchpad.net/bugs/1415098 Title: [connectivity-service] Extend the connectivity-api for WiFi scanning Status in indicator-network package in Ubuntu: New 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.net.wifi.ScanResult object on 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1415098/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
