Bluetooth

From AsteroidOS

An app named AsteroidOSSync can be downloaded on Android to synchronize data from a phone to an AsteroidOS watch. Several profiles are already supported: Notifications, Weather, Music and Battery, more could come in the future.

Technical details

On the phone, AsteroidOSSync uses the SweetBlue library to access the Bluetooth Low Energy capabilities of Bluedroid as a central device. It scans for watches and implements the client part of the aforementioned profiles. On the watch, data are usually received by a BCM20715 BT chip from Broadcom, this chip needs a proprietary firmware which is uploaded by the patchram systemd service. Once the firmware is uploaded an hci0 interface is created and can be set up with hciconfig. The Linux Kernel can then receive BLE payloads. A newer Bluetooth subsystem (4.1) has been backported to provide newer MGMT API functionalities needed by the userspace (e.g: DBus advertisement). This MGMT API is only used by the BlueZ5’s bluetoothd daemon which exposes various DBus abstraction API. Bluetoothd also had to be patched to expose more complete advertisement payloads. Simple and common interactions with the bluetoothd’s DBus API like checking for the powered/connected status are implemented in org.asteroid.utils.BluetoothStatus of qml-asteroid. This class is for example used in asteroid-launcher, asteroid-music and asteroid-settings. More complex interactions with bluetoothd are implemented in asteroid-btsyncd, a user-space daemon running as a standard user (ceres) and acting as a DBus multiplexer between BlueZ and the apps. On the BlueZ side it registers BLE Services, Characteristics and Advertisement payloads. On the user side, it exposes specific API for each and every usage needed. For example, it communicates with asteroid-music with to the MPRIS API, with asteroid-launcher based on the FreeDesktop’s notification API or with asteroid-weather thanks to data saved in the dconf “register”.

Bluetooth Personal Area Network

In order to use BT PAN on AsteroidOS, you first need to modify the default image. Start by adding the following packages to the IMAGE_INSTALL variable of asteroid/src/meta-asteroid/classes/asteroid-image.bbclass:

bluez5-testtools bluez5-noinst-tools python-dbus connman-client

You also need to modify the bluez5’s main configuration in asteroid/src/meta-asteroid/recipes-connectivity/bluez5/bluez5/main.conf to

[General]
#ControllerMode = le
DiscoverableTimeout = 180

Finally, modify build/conf/bblayers.conf to add the following line to BBLAYERS:

/path/to/src/meta-openembedded/meta-networking \

After above changes, you can rebuild a new asteroid rootfs and install it to the watch as described in Building AsteroidOS. In order to watch logs and check on progress, open up first a first terminal on the watch via SSH and run:

tail -F /var/log/messages

In a new terminal, download and push the bt-pan helper script: (more info)

wget https://raw.githubusercontent.com/mk-fg/fgtk/master/bt-pan
chmod +x ./bt-pan
scp bt-pan ceres@192.168.2.15:/tmp/bluetooth/bt-pan

Now, fix up DNS and make sure localhost is a known thing by modifying (if needed) resolv.conf and hosts

sh-4.3# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver ::1
sh-4.3# cat /etc/hosts
127.0.0.1 localhost

Make sure you can see bluetooth in connman:

sh-4.3# connmanctl technologies
...
/net/connman/technology/bluetooth
Name = Bluetooth
Type = bluetooth
Powered = True
Connected = False
Tethering = False

You can now use bluetoothctl to establish a connection to your computer (more info)

sh-4.3# bluetoothctl
[NEW] Controller 20:70:02:A0:1F:AC dory [default]
[NEW] Device 3C:15:C2:C7:DA:95 my-rmbp2
agent on
default-agent
discoverable on
pairable on
scan on
pair 3C:15:C2:C7:DA:95
trust 3C:15:C2:C7:DA:95

Launch bt-pan client which triggers bnep0 creation from connman (you will see it in /var/log/messages)

sh-4.3# /tmp/bluetooth/bt-pan --debug client 3C:15:C2:C7:DA:95
DEBUG:root:Using local device (addr: 20:70:02:A0:1F:AC): /org/bluez/hci0
DEBUG:root:Using remote device (addr: 3C:15:C2:C7:DA:95): /org/bluez/hci0/dev_3C_15_C2_C7_DA_95
DEBUG:root:Connected to network (dev_remote: /org/bluez/hci0/dev_3C_15_C2_C7_DA_95, addr: 3C:15:C2:C7:DA:95) uuid 'nap' with iface: bnep0
DEBUG:root:Finished

At this point your default route should still be rndis0 (USB OTG) instead of bnep0:

sh-4.3# ip route
default via 192.168.2.1 dev rndis0
192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15

If the ip/bcast/netmask fields are missing on bnep0:

sh-4.3# ifconfig bnep0
bnep0 Link encap:Ethernet HWaddr 20:70:02:A0:1F:AC
inet6 addr: fe80::2270:2ff:fea0:1fac%1202001524/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10504 (10.2 KiB) TX bytes:148 (148.0 B)

Fix it with ifconfig and verify it worked:

sh-4.3# ifconfig bnep0 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
sh-4.3# ifconfig bnep0
bnep0 Link encap:Ethernet HWaddr 20:70:02:A0:1F:AC
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::2270:2ff:fea0:1fac%1201331708/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40369 (39.4 KiB) TX bytes:252 (252.0 B)

Now that both routes are available, data are still going over rndis0 instead of bnep0:

sh-4.3# ip route
default via 192.168.2.1 dev rndis0
192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15
192.168.2.0/24 dev bnep0 proto kernel scope link src 192.168.2.2

Delete default route and aad a new default one over bnep0

sh-4.3# ip route delete default
sh-4.3# ip route change default via 192.168.2.1 dev bnep0

Verify default is now over bnep0:

sh-4.3# ip route
default via 192.168.2.1 dev bnep0
192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15
192.168.2.0/24 dev bnep0 proto kernel scope link src 192.168.2.2

You can now test your connection via ping and nslookup

sh-4.3# ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=42 time=80.094 ms
sh-4.3# nslookup www.google.com
Server: 8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com

Bluetooth Audio and HID

You will need to enable legacy mode in order to connect to legacy (BR/EDR) mode Bluetooth devices. To enable legacy mode you will need to edit the configuration file on the watch via SSH use the following command:

sh-4.4# vi /etc/bluetooth/main.conf

Now edit the contents to the following:

[General]
#ControllerMode = le
DiscoverableTimeout = 180

Next you will need to restart Bluetooth. To avoid weird behaviour its best to restart the entire system, use the following command:

sh-4.4# reboot

Now you are ready to connect a Bluetooth device to AsteroidOS use bluetoothctl to connect to a Bluetooth device:

sh-4.4# bluetoothctl
Agent registered
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
[bluetooth]# discoverable on
[bluetooth]# pairable on
[bluetooth]# scan on
Default agent request successful
Changing pairable on succeeded
Changing discoverable on succeeded
[CHG] Controller 43:43:A0:12:1F:AC Discoverable: yes
Discovery started
[CHG] Controller 43:43:A0:12:1F:AC Discovering: yes
[NEW] Device 27:EC:10:01:00:1A Gamepad.
[bluetooth]# pair 27:EC:10:01:00:1A
Attempting to pair with 27:EC:10:01:00:1A
[CHG] Device 27:EC:10:01:00:1A Paired: yes
Pairing successful
[Gamepad.]# connect 27:EC:10:01:00:1A
Attempting to connect to 27:EC:10:01:00:1A
Connection successful
[Gamepad.]#