Skip to content

Changes

Page history
Edit Wi-Fi section. authored by akwizgran's avatar akwizgran
Show whitespace changes
Inline Side-by-side
Public-Mesh-Research-Report.md
View page @ 6946fc78
......@@ -609,7 +609,8 @@ On Android, connections to Wi-Fi access points are managed through the `WifiMana
<https://developer.android.com/reference/android/net/wifi/WifiManager>
A device connected to an access point can use TCP and UDP to communicate with other clients on the same network, if the access point allows it.
A device connected to an access point can use TCP and UDP to communicate with other clients on the same network, if the network allows clients to communicate with each other.
This is typically allowed on networks with a single access point, but may not be supported on larger networks.
To use Wi-Fi when the device's screen is turned off, it can be helpful to hold a `WifiLock` with lock mode `WIFI_MODE_FULL_HIGH_PERF` to keep the Wi-Fi radio awake:
......@@ -634,41 +635,54 @@ The `wifi-client-request-network` branch uses three different techniques for req
This method is available on Android versions 10 and later (API level 29) and was tested on the Samsung Galaxy A21s and Nokia 1.3.
When the app requests the network, the system shows a progress indicator and searches for the network nearby. If the network isn't found, the system shows a dialog with options to try again or cancel. If the network is found, the system shows a dialog asking the user whether to connect or cancel. The app receives a callback with the user's response. If the device is already connected to a Wi-Fi network with internet access, it disconnects and connects to the requested network instead.
When the app requests a connection to a specific network, the system shows a progress indicator and searches for the network nearby.
If the network isn't found, the system shows a dialog with options to try again or cancel.
If the network is found, the system shows a dialog asking the user whether to connect or cancel.
The app receives a callback with the user's response.
If the device is already connected to a Wi-Fi network with internet access, it disconnects and connects to the requested network instead.
The requested network does not appear in the device's list of saved networks.
As expected, there is no warning about lack of internet access and the device stays connected to the network.
As expected, there is no warning about lack of internet access and the device stays connected to the requested network.
The app can disconnect from the requested network by unregistering the `NetworkCallback`. After doing this, reconnecting to the requested network requires confirmation from the user again.
The app can disconnect from the requested network by unregistering the `NetworkCallback`.
After doing this, reconnecting to the requested network requires confirmation from the user again.
The docs [seem to suggest](https://developer.android.com/guide/topics/connectivity/wifi-bootstrap#bypass-approval) that the app can reconnect to the requested network in future without needing user approval again, but we couldn't confirm this behaviour (tested with the Samsung Galaxy A21s as client and the Nokia 1.3 providing a Wi-Fi Direct legacy mode access point).
There doesn't seem to be a way to disconnect from the requested network without calling `ConnectionManager#unregisterNetworkCallback()`, which (per the docs and confirmed by testing) disconnects and forgets the network, thus requiring user confirmation for reconnection. `WifiManager#disconnect()` returns false, while `WifiManager#getConnectionInfo()` returns a `WifiInfo` with its network ID set to -1, so `WifiManager#disableNetwork()` (which requires a valid network ID) can't be used either.
There doesn't seem to be a way to disconnect from the requested network without calling `ConnectionManager#unregisterNetworkCallback()`, which (per the docs and confirmed by testing) disconnects and forgets the network, thus requiring user confirmation for reconnection.
`WifiManager#disconnect()` returns false, while `WifiManager#getConnectionInfo()` returns a `WifiInfo` with its network ID set to -1, so `WifiManager#disableNetwork()` (which requires a valid network ID) can't be used either.
If the access point is stopped and restarted, thus forcing the client to disconnect, the client asks for user confirmation again when reconnecting, even if the same NetworkRequest and NetworkCallback instances are used. The client asks for user confirmation even if it's currently connected to the requested network.
If the access point is stopped and restarted, thus forcing the client to disconnect, the system asks for user confirmation again when reconnecting, even if the same `NetworkRequest` and `NetworkCallback` instances are used.
The system asks for user confirmation even if it's currently connected to the requested network.
##### 2. `WifiManager#enableNetwork()`
This method is available on Android versions 9 and earlier (API level 28) and was tested on the LGE Nexus 5X, Moto G 4G and Honor 8A.
The app creates a `WifiConfiguration` with a high priority value, adds the configuration via `WifiManager#addNetwork()`, and enables the configuration via `WifiManager#enableNetwork()`. This doesn't require user approval and connects to the requested network immediately, even if the device is currently connected to a network with internet access and the requested network doesn't have internet access. The Honor 8A sometimes reconnects to the network with internet access instead of connecting to the requested network.
The app creates a `WifiConfiguration` with a high priority value, adds the configuration via `WifiManager#addNetwork()`, and enables the configuration via `WifiManager#enableNetwork()`.
This doesn't require user confirmation and connects to the requested network immediately, even if the device is currently connected to a network with internet access and the requested network doesn't have internet access.
The Honor 8A sometimes reconnects to the network with internet access instead of connecting to the requested network.
A few seconds after connecting to the requested network, the Honor 8A shows a dialog that warns about lack of internet access. Regardless of whether "Cancel" or "Connect" is chosen, the device stays connected to the requested network.
A few seconds after connecting to the requested network, the Honor 8A shows a dialog that warns about lack of internet access.
Regardless of whether "Cancel" or "Connect" is chosen, the device stays connected to the requested network.
On the other test devices there is no warning about lack of internet access and the device stays connected to the network.
The requested network is added to the device's list of saved networks.
There is no warning about lack of internet access and the device stays connected to the network.
The app can disconnect from the requested network and remove the saved configuration by calling `WifiManager#removeNetwork()`.
TCP connection attempts from the client devices to the device providing the access point (Nokia 1.3) can take several seconds to connect.
TCP connection attempts from the client devices to the device providing the access point (Nokia 1.3) can take several seconds to connect, which is unexpected on a LAN.
##### 3. `WifiManager#connect()`
This method is available on Android versions 9 and earlier (API level 28) and was tested on the LGE Nexus 5X, Moto G 4G and Honor 8A.
As in the previous method, the app creates a `WifiConfiguration` with a high priority value and adds the configuration via `WifiManager#addNetwork()`. The app then uses reflection to call `WifiManager#connect()`. This appears to behave identically to the previous method.
As in the previous method, the app creates a `WifiConfiguration` with a high priority value and adds the configuration via `WifiManager#addNetwork()`.
The app then uses reflection to call `WifiManager#connect()`.
This method appears to behave identically to the previous method.
##### Summary
......@@ -702,6 +716,8 @@ The device providing the access point may not be able to connect to clients, how
We still need to test whether LAN multicast and the NSD API can be used (by clients and/or the device providing the access point) on networks where the access point is created through each of these methods.
Some devices can provide an access point while simultaneously being a client of another Wi-Fi network, which might make it possible to create a mesh in which each device would act as a client, an access point, or both.
### Wi-Fi Direct
#### Peer Advertisement
......@@ -714,22 +730,24 @@ We still need to test whether LAN multicast and the NSD API can be used (by clie
### Ad Hoc Mode
The original Wi-Fi standard defines two modes of operation: infrastructure mode, in which stations communicate via an access point, and ad hoc mode, in which stations communicate directly with each other. Ad hoc mode could potentially be useful for creating smartphone-based mesh networks.
The original Wi-Fi standard defines two modes of operation: infrastructure mode, in which stations communicate via an access point, and ad hoc mode, in which stations communicate directly with each other.
Ad hoc mode could potentially be useful for creating smartphone-based mesh networks.
Unfortunately this mode has never gained traction among implementers of the standard: not all chipsets support ad hoc mode, and there is no Android API for accessing this mode, even if the chipset supports it.
### Wi-Fi Aware (Neighbor Awareness Networking)
Wi-Fi Aware is a relatively recent addition to the Wi-Fi standard that has some similarities to ad hoc mode and Wi-Fi Direct. Devices can discover and connect to other nearby devices, and can advertise and discover services, without the need for an access point.
Wi-Fi Aware, also known as Neighbor Awareness Networking or NAN, is a relatively recent addition to the Wi-Fi standard that has some similarities to ad hoc mode and Wi-Fi Direct.
Devices can discover and connect to other nearby devices, and can advertise and discover services, without the need for an access point.
Compared to Wi-Fi Direct, Wi-Fi Aware is designed to enable continuous, low-power discovery of nearby devices.
* https://www.wi-fi.org/discover-wi-fi/wi-fi-aware
* https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi%20Aware%20Specification%20v4.0.pdf
* <https://www.wi-fi.org/discover-wi-fi/wi-fi-aware>
* <https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi%20Aware%20Specification%20v4.0.pdf>
Android provides an API for Wi-Fi Aware on API levels 26 and later, if the hardware supports it:
https://developer.android.com/guide/topics/connectivity/wifi-aware.html
<https://developer.android.com/guide/topics/connectivity/wifi-aware.html>
We tested several devices to see whether the Wi-Fi Aware API was supported:
......@@ -745,11 +763,12 @@ We tested several devices to see whether the Wi-Fi Aware API was supported:
| Samsung Galaxy A10s (SM-A107F/DS) | 11 (One UI Core 3.1) | 30 | No |
| Sony XZ2 (H8216) | 10 | 29 | No |
These results suggest that Wi-Fi Aware is not useful for creating smartphone-based mesh networks at present, due to the small number of devices implementing the standard. It may become suitable in future if widely implemented in smartphones.
These results suggest that Wi-Fi Aware is not useful for creating smartphone-based mesh networks at present, due to the small number of devices implementing the standard.
It may become suitable in future if widely implemented in smartphones.
The following list of Wi-Fi Aware certified devices may be useful for determining whether this is happening:
The following list of Wi-Fi Aware certified devices may be useful for determining whether this is starting to happen:
https://www.wi-fi.org/product-finder-results?sort_by=certified&sort_order=desc&certifications=757
<https://www.wi-fi.org/product-finder-results?sort_by=certified&sort_order=desc&certifications=757>
## Other Android APIs
......