Skip to content

Changes

Page history
Add section on Wi-Fi scanning. authored by akwizgran's avatar akwizgran
Show whitespace changes
Inline Side-by-side
Public-Mesh-Research-Report.md
View page @ 1f4ad18f
...@@ -445,6 +445,7 @@ Services are discovered by specifying a service type. ...@@ -445,6 +445,7 @@ Services are discovered by specifying a service type.
The app receives the instance name and attributes of discovered services. The app receives the instance name and attributes of discovered services.
However, some devices (eg Huawei P8 Lite 2015, Moto G 4G, Moto E3) don't receive the attributes. However, some devices (eg Huawei P8 Lite 2015, Moto G 4G, Moto E3) don't receive the attributes.
This appears to be an Android bug that was fixed in Android version 7 (API level 24): This appears to be an Android bug that was fixed in Android version 7 (API level 24):
<https://issuetracker.google.com/issues/37020436> <https://issuetracker.google.com/issues/37020436>
#### Peer Connectivity #### Peer Connectivity
...@@ -463,6 +464,7 @@ It seems, however, that sometimes resolving neither succeeds nor fails, but inst ...@@ -463,6 +464,7 @@ It seems, however, that sometimes resolving neither succeeds nor fails, but inst
The `lan-service-discovery-nsd-no-resolution` branch encodes the IP address in the NSD service name, allowing us to skip the buggy resolution step. The `lan-service-discovery-nsd-no-resolution` branch encodes the IP address in the NSD service name, allowing us to skip the buggy resolution step.
This means we can't advertise attributes, unless we encode them in the service name along with the address, or fetch them separately via unicast. This (abandoned) library implements the latter approach to work around the empty attributes map issue mentioned above: This means we can't advertise attributes, unless we encode them in the service name along with the address, or fetch them separately via unicast. This (abandoned) library implements the latter approach to work around the empty attributes map issue mentioned above:
<https://github.com/youviewtv/tinydnssd> <https://github.com/youviewtv/tinydnssd>
Alternatively we could implement our own unicast protocol for fetching attributes, while still using NSD for the multicast part, to benefit from the special treatment it seems to get on some devices. Alternatively we could implement our own unicast protocol for fetching attributes, while still using NSD for the multicast part, to benefit from the special treatment it seems to get on some devices.
...@@ -533,11 +535,20 @@ To use Wi-Fi when the device's screen is turned off, it can be helpful to hold a ...@@ -533,11 +535,20 @@ To use Wi-Fi when the device's screen is turned off, it can be helpful to hold a
#### Scanning for Available Networks #### Scanning for Available Networks
TODO Android allows apps to scan for available Wi-Fi Networks:
<https://developer.android.com/guide/topics/connectivity/wifi-scan>
Starting a scan requires some combination of the `ACCESS_FINE_LOCATION`, `ACCESS_COARSE_LOCATION` and `CHANGE_WIFI_STATE` permissions, depending on the API level.
On Android versions 9 and later (API level >= 28), the device's location services must also be enabled.
On Android versions 10 and later (API level >= 29), receiving the results of a scan requires the `ACCESS_WIFI_STATE` permission in addition to the requirements above. An app can be notified when scans triggered by the system or other apps have completed, allowing it to receive updated results without triggering its own scans.
The rate at which apps can trigger scans is throttled on Android versions 8.0 and later (API level >= 26). An app can only scan once every 30 minutes while running in the background. This makes it impractical to use Wi-Fi scans to detect mesh devices that may only be in range for a short time.
#### Connecting to a Specific Network #### Connecting to a Specific Network
It might be useful for mesh peers to be able to connect to specific Wi-Fi access points without user interaction - particularly access points provided by other mesh peers (eg local-only hotspots or Wi-Fi Direct legacy mode access points). It might be useful for a mesh app to be able to connect to specific Wi-Fi access points without user interaction - particularly access points provided by other mesh devices (eg local-only hotspots or Wi-Fi Direct legacy mode access points).
The network names and passwords of these access points could be distributed via other transports, such as BLE advertising or Wi-Fi Direct service discovery. The network names and passwords of these access points could be distributed via other transports, such as BLE advertising or Wi-Fi Direct service discovery.
......