Public-Mesh-Research-Report.md

@@ -605,7 +605,8 @@ https://invent.kde.org/network/kdeconnect-android/-/blob/master/src/org/kde/kdec
 
 Wi-Fi is widely supported by smartphones and other mobile devices, and allows for easy interoperation between platforms.
 
-Although Wi-Fi communication typically requires an access point (with some exceptions, see below), access points are available worldwide, are under local control, and may be usable (without internet access) even during internet shutdowns.
+Wi-Fi communication typically requires an access point (with some exceptions, see below).
+Access points are available worldwide, are under local control, and may be usable (without internet access) even during internet shutdowns, so they meet our criteria for infrastructure that's suitable for use in a smartphone-based mesh.
 
 ### Wi-Fi Client
 
@@ -710,10 +711,11 @@ Some devices require a SIM card to be inserted before this feature can be used.
 On Android versions 5.1 and earlier (API level <= 22), applications can use reflection to access a hidden API for enabling an access point, including specifying the network name and password.
 
 Android versions 8 and later (API level >= 26) have an API for creating a "local-only hotspot", which is an access point that doesn't provide internet access to connected clients.
+The application can't choose the hotspot's network name or password.
 
 <https://developer.android.com/reference/android/net/wifi/WifiManager#startLocalOnlyHotspot(android.net.wifi.WifiManager.LocalOnlyHotspotCallback,%20android.os.Handler)>
 
-A local-only hotspot is similar to a Wi-Fi Direct legacy mode access point, which is described in the Wi-Fi Direct section.
+A local-only hotspot is similar to a Wi-Fi Direct legacy mode access point, which is described in the [Wi-Fi Direct section](#wi-fi-direct).
 
 When using any of these methods to create an access point, clients connected to the access point can typically connect to each other, and to the device providing the access point, via TCP and UDP.
 The device providing the access point may not be able to connect to clients, however, because Android treats the access point's network interface differently from other network interfaces.
@@ -784,6 +786,8 @@ Given that apps have a limited ability to scan for available Wi-Fi networks, it
 In this scenario the password would be considered public knowledge, and would not be relied on for any kind of security.
 The password would only exist to meet the transport layer's requirement that a password should be specified.
 
+#### Connecting to an Access Point with Predefined Credentials
+
 To test whether this idea was feasible, we investigated the following questions:
 
 ##### 1. Can we request a connection to a network that's not currently in range? If so, do we connect automatically when the network comes into range?
@@ -811,14 +815,37 @@ On the Moto G 4G it appears to be a matter of policy not to reconnect automatica
 On other devices (eg Huawei P8 Lite 2015), it may depend on whether the client has dropped its connection to the network with internet access during sleep, giving the requested network a chance to be chosen when the device wakes up.
 
 When no network with internet access is available, some devices may connect automatically to the second access point of the requested network when it comes into range.
-The Moto G 4G won't do this as a matter of policy.
-On other devices (eg Honor 8A, Moto E3), it may not happen until a scan for available Wi-Fi networks is triggered.
+As mentioned above, the Moto G 4G won't do this as a matter of policy.
+Other devices (eg Honor 8A, Moto E3) may not connect to the second access point of the requested network until a scan for available Wi-Fi networks is triggered.
 The rate at which apps can trigger these scans is throttled on later API levels.
-The system may trigger a scan when the screen is turned on.
+The system may trigger a scan when the screen is turned on, resulting in the device connecting to the requested network.
 
 On Android versions 10 and later (API level >= 29), we did not manage to trigger automatic reconnection to a network requested via the `WifiNetworkSpecifier` API, regardless of whether the client was reconnecting to the same access point or a second access point with the same network name and password.
 
 We have not yet tested whether the `WifiP2pManager` (Wi-Fi Direct) API can be used to roam between legacy mode access points with the same network name and password on Android versions 10 and later.
+However, the tests described above for reconnecting to the same access point would seem to suggest that periodically trying to connect via the `WifiP2pManager` API is likely to work also for the case of roaming between access points.
+
+#### Creating an Access Point with Predefined Credentials
+
+As described in the [Wi-Fi Access Point](#wi-fi-access-point) and [Wi-Fi Direct](#wi-fi-direct) sections, there are only two ways for an Android app to create an access point with a specified network name and password:
+
+* On Android versions 5.1 and earlier (API level <= 22), apps can use reflection to access a hidden API for creating an access point that shares the device's internet connection with connected clients.
+* On Android versions 10 and later (API level >= 29), apps can use the `WifiP2pManager` API to create a Wi-Fi Direct legacy mode access point with a specified network name and password.
+
+These API level constraints mean that not every device in a smartphone-based mesh would be able to act as an access point with the predefined credentials.
+
+#### Summary
+
+All the Android devices we tested were capable of connecting to an access point with a predefined network name and password, without needing to trigger a scan for available networks or access the results of a previous scan.
+On Android versions 9 an earlier (API level <= 28), this was done via the `WifiManager` API.
+On Android versions 10 and later (API level >= 29) it was done via the `WifiP2pManager` API.
+
+Devices varied in their behaviour when connecting to an access point without internet access, and when roaming between access points with the same network name and password.
+This could make it challenging to create a consistent user experience.
+
+Android versions 9 and earlier (API level <= 28) would be vulnerable to the ["soft AP attack"]{#soft-ap-attack) when acting as clients.
+
+Not all devices would be able to act as access points, and users would not be able to control which of the available access points their devices would connect to, so this technique would need to be used in combination with other transport layers.
 
 ## Other Android APIs
 
@@ -847,13 +874,21 @@ Connections are always made via Bluetooth RFCOMM initially. The advertiser encod
 
 The advertiser may then tell the discoverer to switch from Bluetooth to Wi-Fi. Wi-Fi connections may use an existing access point if both devices are connected to the same access point. If not, Wi-Fi connections may use Wi-Fi Direct (legacy mode) or `hostapd`. The advertiser creates an access point via Wi-Fi Direct or `hostapd` and sends the access point's network name and password to the discoverer via the Bluetooth connection. The discoverer disconnects from its existing access point, if any, and connects to the access point specified by the advertiser.
 
-#### Soft AP attack
+#### Soft AP Attack
 
-The researchers identified several attacks against Nearby, including the "soft AP attack", in which a malicious advertiser instructs the discoverer to switch to an access point that has internet access. This unexpectedly causes the discoverer's device to route all its traffic through that access point.
+The "Nearby Threats" researchers identified several attacks against Nearby, including the "soft AP attack", in which a malicious advertiser instructs the discoverer to switch to an access point that has internet access.
+This unexpectedly causes the discoverer's device to route all its traffic through that access point.
 
-Due to this attack, it is not safe to use the Wi-Fi client (`WifiManager`) API for connecting to a Wi-Fi Direct legacy mode access point provided by another device.
+Due to this attack, it is not safe to use the Wi-Fi client (`WifiManager`) API for connecting to an access point provided by another device, including a Wi-Fi Direct legacy mode access point.
 However, it appears to be safe to use the Wi-Fi Direct (`WifiP2pManager`) API for connecting to a legacy mode access point, as in this case the client will not route all its traffic through the access point even if the access point unexpectedly provides internet access.
 
+We confirmed this by using `wpa_supplicant` and `udhcpd` on Linux to create a Wi-Fi Direct group with the Linux device as the group owner.
+`udhcpd` was configured to provide a default route to connected clients, and `iptables` was used to share the Linux device's internet connection with clients.
+
+When connecting to the Linux device as an ordinary Wi-Fi access point, Android devices would route their traffic through the access point, showing that `udhcpd` and `iptables` were configured correctly.
+But when connecting to the access point via the Wi-Fi Direct API, Android devices would not route their traffic through the access point.
+This was tested with the Samsung Galaxy A21s, LGE Nexus 5X and Moto G 4G.
+
 ## Alternative Transports
 
 ### OuiSync