| ... | ... | @@ -33,7 +33,12 @@ The bulk of this research is therefore concerned with understanding and evaluati |
|
|
|
|
|
|
|
# Transport Layers
|
|
|
|
|
|
|
|
The base layer of any mesh networking protocol is the individual direct connections between peer devices. In this section we explore a set of possible transport layers for discovering and connecting to peer devices.
|
|
|
|
The base layer of any mesh networking protocol is the individual direct connections between devices.
|
|
|
|
In this section we explore a set of possible transport layers for discovering and connecting to nearby devices.
|
|
|
|
|
|
|
|
For each transport layer, we aim to understand how it can be used in theory, what APIs are available for using it on Android, how it performs on a variety of real devices, and how it might affect the user experience of a mesh application (for example, by requiring user confirmation for certain actions).
|
|
|
|
|
|
|
|
Although we have evaluated the various transport layers on Android, we are also interested in whether they can interoperate with other platforms, include iOS, Windows, Linux and macOS.
|
|
|
|
|
|
|
|
Some of the transport layers covered by this research are already used in the Briar messaging app, but by removing the constraint that devices only connect to contacts, we change the ways in which familiar transports can be used, so we need to look at them again with the public mesh strategy in mind.
|
|
|
|
|
| ... | ... | @@ -42,18 +47,6 @@ Several of the transports discussed below have advertising and discovery mechani |
|
|
|
|
|
|
|
## Prologue
|
|
|
|
|
|
|
|
### Evaluation Criteria
|
|
|
|
|
|
|
|
We are looking for transport layers that enable the creation of smartphone-based mesh networks. To achieve this, a transport layer must enable smartphones to discover and/or connect to other smartphones nearby, either with or ideally without the support of infrastructure.
|
|
|
|
|
|
|
|
If infrastructure is needed, it must be of a kind that is already widely deployed worldwide and under the effective control of ordinary people at a local level.
|
|
|
|
|
|
|
|
Suitable transport layers must be supported by a wide range of smartphones of different models and manufacturers, and must not require root access, which is only available to technically skilled users and only on certain phone models.
|
|
|
|
|
|
|
|
For each transport layer, we aim to understand how it can be used in theory, what APIs are available for using it on Android, how it performs on a variety of real devices, and how it might affect the user experience of a mesh application (for example, by requiring user confirmation for certain actions).
|
|
|
|
|
|
|
|
Although we have evaluated the various transport layers on Android, we are also interested in whether they can interoperate with other platforms, include iOS, Windows, Linux and macOS.
|
|
|
|
|
|
|
|
### Test Devices
|
|
|
|
|
|
|
|
The following Android devices were used for testing one or more transport layers:
|
| ... | ... | @@ -92,24 +85,13 @@ Bluetooth is a short-range radio technology that comes bundled with most modern |
|
|
|
It allows devices to discover each other and transfer data over a range of about 10 metres.
|
|
|
|
The availability of Bluetooth APIs on most smartphones makes Bluetooth an attractive transport for infrastructure-free data transfers, like those needed for a public mesh system.
|
|
|
|
|
|
|
|
### Resources
|
|
|
|
### Bluetooth "classic" (BR/EDR)
|
|
|
|
|
|
|
|
Background information about Bluetooth:
|
|
|
|
The early generations of the Bluetooth standard, which are now sometimes called "classic" to distinguish them from Bluetooth Low Energy, are supported by nearly all smartphones.
|
|
|
|
|
|
|
|
- Bluetooth Low Energy
|
|
|
|
- <https://punchthrough.com/how-gap-and-gatt-work/>
|
|
|
|
- <https://www.oreilly.com/library/view/getting-started-with/9781491900550/ch04.html>
|
|
|
|
- <https://github.com/weliem/blessed-android>
|
|
|
|
- <https://software-dl.ti.com/lprf/simplelink_cc2640r2_sdk/1.35.00.33/exports/docs/ble5stack/ble_user_guide/html/ble-stack/l2cap.html#l2cap-connection-oriented-channel-coc-example>
|
|
|
|
- <https://code.briarproject.org/briar/public-mesh-testbed/-/tree/blessed-gatt>
|
|
|
|
- Bluetooth "classic", specifically RFCOMM
|
|
|
|
- <https://developer.android.com/guide/topics/connectivity/bluetooth>
|
|
|
|
- <https://code.briarproject.org/briar/public-mesh-testbed/-/tree/bt-classic>
|
|
|
|
|
|
|
|
### Bluetooth "classic" (BR/EDR)
|
|
|
|
|
|
|
|
The early generations of the Bluetooth standard, which are now sometimes called "classic" to distinguish them from Bluetooth Low Energy, are supported by nearly all smartphones.
|
|
|
|
|
|
|
|
#### Discovery
|
|
|
|
|
|
|
|
At any given time, a Bluetooth classic device may be connectable and/or discoverable. A connectable device can receive incoming connections from other devices. A discoverable device can be discovered by other devices that are performing discovery.
|
| ... | ... | @@ -165,10 +147,21 @@ Like Bluetooth classic, BLE allows devices to discover and connect to each other |
|
|
|
|
|
|
|
Once a connection has been made, data may be exchanged using the Generic Attribute Profile (GATT). The peripheral offers one or more GATT services, each consisting of predefined "characteristics": small pieces of data that can be read or written by the central.
|
|
|
|
|
|
|
|
- <https://learn.adafruit.com/introduction-to-bluetooth-low-energy>
|
|
|
|
- <https://punchthrough.com/how-gap-and-gatt-work/>
|
|
|
|
- <https://www.oreilly.com/library/view/getting-started-with/9781491900550/ch04.html>
|
|
|
|
- <https://code.briarproject.org/briar/public-mesh-testbed/-/tree/blessed-gatt>
|
|
|
|
|
|
|
|
More recently, the Bluetooth standard has defined L2CAP Connection-Oriented Channels (CoC), which allow socket-like connections between centrals and peripherals. The server socket on the peripheral device is identified by an ephemeral number called the protocol/service multiplexer (PSM), which must be communicated to the central somehow (eg through BLE advertising, GATT, or out-of-band). Android provides an API for L2CAP CoC on API levels 29 and later if the hardware supports it.
|
|
|
|
|
|
|
|
<https://software-dl.ti.com/lprf/simplelink_cc2640r2_sdk/1.35.00.33/exports/docs/ble5stack/ble_user_guide/html/ble-stack/l2cap.html#l2cap-connection-oriented-channel-coc-example>
|
|
|
|
|
|
|
|
Most Android phones can operate in the central role and some can also operate in the peripheral role, so some pairs of devices can make peer-to-peer BLE connections via GATT or L2CAP CoC.
|
|
|
|
|
|
|
|
#### BLESSED
|
|
|
|
|
|
|
|
We have found that the open source Bluetooth library [BLESSED](https://github.com/weliem/blessed-android) is useful for working with BLE on Android. The project's README.md offers an introduction to the library for new users, and they also offer a number of [example projects](https://github.com/weliem/blessed-android/tree/master/app/src/main/java/com/welie/blessedexample) to help developers get started with BLESSED.
|
|
|
|
|
|
|
|
#### Security
|
|
|
|
|
|
|
|
BLE is designed to allow devices to advertise and discover services continuously with low energy consumption. This creates a privacy risk: a device that is continuously sending packets from the same address can easily be tracked.
|
| ... | ... | @@ -226,21 +219,19 @@ Depending on the API level, various permissions must be granted by the user. On |
|
|
|
* Let app always run in the background
|
|
|
|
* Show notifications
|
|
|
|
|
|
|
|
On API levels 30 and earlier, access to some Bluetooth APIs requires location-related permissions, and access to these APIs while the app is in the background may result in a warning being shown about the app accessing the user's location. This creates a UX hurdle for future public mesh applications because it could cause users to believe their locations are being tracked.
|
|
|
|
On API levels 30 and earlier, access to some Bluetooth APIs requires location-related permissions.
|
|
|
|
If the app does not use a [foreground service](https://developer.android.com/guide/components/foreground-services) then the `ACCESS_BACKGROUND_LOCATION` permission is needed on Android versions 10 and 11 (API 29 and 30) for accessing Bluetooth APIs while the app is in the background.
|
|
|
|
Using this permission may result in a warning being shown about the app accessing the user's location.
|
|
|
|
This creates a UX hurdle for future public mesh applications because it could cause users to believe their locations are being tracked.
|
|
|
|
|
|
|
|
On Android versions 6 and later (API level >= 23), the device's location services must be enabled in order for apps to receive BLE discovery results.
|
|
|
|
|
|
|
|
#### BLE Open Questions
|
|
|
|
|
|
|
|
* What is the maximum number of GATT Characteristics allowed on each popular Android device?
|
|
|
|
* What is the maximum MTU on each popular Android device?
|
|
|
|
During our research, the Nexus 5x, Pixel 3a, 4, and 5 all had the highest possible maximum MTU size of 512 bytes, but this is not always a given.
|
|
|
|
* What is the MTU on each popular Android device? During our research, the Nexus 5X, Pixel 3a, 4, and 5 all had the highest possible MTU size of 512 bytes, but this is not always a given.
|
|
|
|
* Is the Linux [Bluez](https://www.bluez.org/) library affected by the silent pairing bug (CVE-2020-12856)?
|
|
|
|
|
|
|
|
### BLESSED
|
|
|
|
|
|
|
|
We have found that the open source Bluetooth library [BLESSED](https://github.com/weliem/blessed-android) is useful for working with BLE on Android. The project's README.md offers an introduction to the library for new users, and they also offer a number of [example projects](https://github.com/weliem/blessed-android/tree/master/app/src/main/java/com/welie/blessedexample) to help developers get started with BLESSED.
|
|
|
|
|
|
|
|
#### Peer Advertisement
|
|
|
|
|
|
|
|
Peer advertisement happens using BLE's advertisement protocol, which allows a peripheral device to send small advertisement packets periodically.
|
| ... | ... | @@ -340,7 +331,7 @@ Then, whenever we discover an L2CAP-compatible device, we can connect to it usin |
|
|
|
- The Moto G can't connect to the J5 via GATT: it receives a callback to `onConnectingPeripheral()`, never receives `onConnectedPeripheral()`, and eventually receives `onDisconnectedPeripheral()` with status `LMP_OR_LL_RESPONSE_TIMEOUT`. The J5 receives `onCentralConnected()` and `onCentralDisconnected()` as expected. The J5 can subsequently connect back to the Moto G, using the address it learned from the unsuccessful connection, and exchange pings and pongs.
|
|
|
|
- When the J5 receives a connection from the Moto G or P8 Lite, the J5 sees the same address that the Moto G/P8 Lite gets from its own `BluetoothAdapter`, ie the BT classic address.
|
|
|
|
|
|
|
|
### Socket-Like Communication via GATT
|
|
|
|
#### Socket-Like Communication via GATT
|
|
|
|
|
|
|
|
GATT makes it easy to implement services in which a central and a peripheral exchange small pieces of data in a predefined structure.
|
|
|
|
However, as we're interested in building a protocol stack where the higher-layer protocols may operate over a mixture of transport layers, it would be useful if the various transport layers could provide similar abstractions.
|
| ... | ... | @@ -351,7 +342,7 @@ This can be done by defining a service with two characteristics: a "read charact |
|
|
|
|
|
|
|
This `blessed-gatt` testbed branch demonstrates this technique.
|
|
|
|
|
|
|
|
### BLE Allocator Characteristic
|
|
|
|
#### BLE Allocator Characteristic
|
|
|
|
|
|
|
|
One of the core features for a performative ad-hoc mesh system is the ability to make simultaneous p2p connections between multiple devices.
|
|
|
|
We found that some of the test devices could support simultaneous GATT connections to multiple peripherals when acting as a central.
|
| ... | ... | @@ -388,7 +379,7 @@ The full handshake as implemented in the `blessed-gatt-allocator-vuln` and `bles |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Notes
|
|
|
|
##### Notes
|
|
|
|
|
|
|
|
* The allocator characteristic works as an active list of nearby peers, so higher level protocols could possibly utilize this as a way to further increase peer discovery and data propagation.
|
|
|
|
* Because each peripheral has a limited number of read characteristics, protocols built on top of this strategy should prioritize quicker, more frequent connections rather than long lasting data transfers.
|
| ... | ... | @@ -400,7 +391,7 @@ This allows L2CAP CoC to be used between centrals and peripherals that support i |
|
|
|
If the communication between a peripheral and a central needs to be confidential then higher-layer protocols must ensure that this remains the case even when the data sent from the peripheral to the central can easily be observed by other devices nearby.
|
|
|
|
In practice this is unlikely to make a big difference to the design of higher-layer protocols, which must already be designed around the assumption that any data sent over a wireless medium can easily be received by unintended recipients.
|
|
|
|
|
|
|
|
### BluetoothCommunicator
|
|
|
|
#### BluetoothCommunicator
|
|
|
|
|
|
|
|
BluetoothCommunicator is a BLE library built upon the core Android `BluetoothGATT` objects similar to BLESSED. However, unlike BLESSED, BluetoothCommunicator is geared more towards async messaging, and not a general-use library.
|
|
|
|
|
| ... | ... | |
