Experiences with Bluetooth on Arch Linux ARM

This article summarises the experiences of configuring bluetooth on Arch Linux ARM on the Raspberry Pi. The author uses an Asus BT-400 dongle for bluetooth for the purpose of sharing files with other devices. At the time of writing, bluetooth support for this device is proving unstable, e.g. sometimes, the device is not recognised at system boot.

BlueZ is the linux implementation of the bluetooth protocol stack. Since version 5.35+, a new set of utilities for configuring bluetooth have been provided with BlueZ. This includes utilities such as bluetoothctl, btmgmt etc. At the time of writing, official documentation is poorly documented. For example, no man pages are provided for bluetoothctl or btmgmt. Documentation on the Arch Linux Wiki, summarises the utility toolset. However, it is currently evident that troubleshooting documentation requires updating to reference examples, concerning usage of the new toolset.

Prerequisites

The following packages are required for bluetooth usage in Arch Linux ARM.

• bluez: Implementation of the bluetooth protocol stack.
• bluez-utils: Utility toolset for configuring bluetooth.

Furthermore, the bluez-utils-compat package provides the old utility toolset for configuring bluetooth. This is available in AUR.

The bluetooth daemon only provides access to bluetooth devices for users that are members of the lp group. Subsequently, ensure that users are members of the lp group.

usermod -aG lp alarm

Installing Bluetooth

The generic bluetooth driver is btusb. This can be loaded, using the modprobe utility.

modprobe -v btusb

Furthermore, it may be necessary to run pulseaudio if driver problems are evident in the system logs and/or require usage of a bluetooth headset.

pulseaudio --start

Subsequently, the bluetooth service can then be started and enabled to run during system boot.

sudo systemctl start bluetooth
sudo systemctl enable bluetooth

The main configuration file for bluetooth is available at /etc/bluetooth/main.conf. To enable bluetooth controllers to be activated at system boot, edit the AutoEnable line at the end of the file as follows:

AutoEnable=true

Check the output of the dmesg command to determine if any problems were encountered initialising the bluetooth device. Refer to the section below and the Arch Wiki for troubleshooting bluetooth devices.

Bluetooth Usage

The utility for managing bluetooth activity can be started by typing bluetoothctl. Enter the following series of commands.

agent on
default-agent
power on
scan on
discoverable on
pairable on

This will perform the following actions:

1. Activate the bluetooth agent.
2. Power on the bluetooth device.
3. Start scanning for discoverable devices.
4. Make the bluetooth device discoverable.
5. Make the bluetooth device pairable.

The following commands are frequently used:

• devices:List the MAC address and name for connectable devices.
• pair:Pair to a device with a given MAC address, e.g.
  

  pair 80:00:0B:54:BA:04
  

• trust:Trust the device with a given MAC address, e.g.
  

  trust 80:00:0B:54:BA:04
  

  
  This will allow auto pairing and connection.
• connect:Connect to a device with a given MAC address, e.g.
  

  connect 80:00:0B:54:BA:04
  

• help: Provide a full listing of commands.
• exit: Exit the bluetoothctl utility.

Bluetooth File Transfer

This section provides a brief summary of obex utilities that allow file transfer between bluetooth devices. These are:

• obexftp
• ussp-push
• obexd

The obexftp and ussp-push utilities are provided in AUR. The obexftp utility requires that the bluetooth daemon is running in compatibility mode for usage of older deprecated API usage in the Bluez library. At the time of writing the author is running Bluez 5.49. This provides the obexd daemon and appears to be the recommended method of file transfer. However, this is poorly documented.

Obex Ftp

Obexftp is an AUR package that provides utilities for file transfer between bluetooth devices. An explanation for building AUR packages is given in a previous article.

The usage for sending a file with obexftp is as follows.

obexftp -b MAC_address_of_device -p /path/to/file

The usage for receiving a file with obexftp is as follows.

obexftp -b MAC_address_of_device -g file_name

The file_name argument is the name of the file located in the source device’s public folder. Specify, subfolder names in the argument if the file to receive is not located in the root public folder of the source device.

There is also a daemon utility, obexftpd. This can be configured to listen for bluetooth connections and serve files from a specific base folder. In the example below the -c switch specifies the base folder and the -b switch specifies that the daemon will listen for bluetooth connections.

obexftpd -c /tmp/inbox -b

Usage of obexftpd as a systemd service, requires that the bluetooth daemon is running in compatibility mode with the older bluetooth toolset API. To achieve this edit the bluetooth.service file at /etc/systemd/system/bluetooth.target.wants so that the daemon is started as follows:

ExecStart=/usr/lib/bluetooth/bluetoothd --compat

Furthermore, the author had to install the bluez-utils-compat package from AUR and then register the OBEX Push profile (OPP) using sdptool:

sdptool add OPUSH

It may be possible to achieve this, without installing the bluez-utils-compat package. This could be achieved by adding the UUID for OPUSH, using the bluetoothctl utility:

bluetoothctl
menu advertise
uuids 00001105-0000-1000-8000-00805f9b34fb
back
advertise on
show
exit

USSP Push

An alternative package also exists in AUR, ussp-push. This can also be used for bluetooth file transfer. At the time of writing, the author has only briefly investigated this utility. Unfortunately, it cannot be used as a daemon.

Obexd

The obexd daemon provides an Object Push Profile (OPP), that has been merged into package bluez-utils. This enables file transfer to and from, peer devices. The author has managed to enable the daemon only at login for all users, using the commands below.

systemctl --global start obex
systemctl --global enable obex

Alternatively, it can be configured for only the calling user, via:

systemctl --user start obex
systemctl --user enable obex

The author has yet to determine how to configure this to run as a system service during boot.

To verify that the obex daemon has been started, start the bluetoothctl utility and enter the following commands to check that the OBEX Object Push service is provided by the system bluetooth controller:

bluetoothctl
show

This should display output similar to the listing below.

Controller 11:11:11:11:11:11 (public)
	Name: raspberrypi.ubuntu.private
	Alias: rpi
	Class: 0x001c0104
	Powered: yes
	Discoverable: yes
	Pairable: yes
	UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: OBEX File Transfer        (00001106-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: OBEX Object Push          (00001105-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: IrMC Sync                 (00001104-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Vendor specific           (00005005-0000-1000-8000-0002ee000001)
	UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
	UUID: Phonebook Access Server   (0000112f-0000-1000-8000-00805f9b34fb)
	UUID: Message Access Server     (00001132-0000-1000-8000-00805f9b34fb)
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v0B05p17CBdABCD
	Discovering: no

If this is not the case try adding the UUID for the OBEX Object Push Profile (OPP) in the advertise menu of the bluetoothctl utility and then ensure that advertising is switched on, as follows:

bluetoothctl
menu advertise
uuids 00001105-0000-1000-8000-00805f9b34fb
back
advertise on
show

The folder location for sending/receiving files can be configured for the obexd daemon using the –root switch. An example, is given in the listing below for the obex systemd service.

[Unit]
Description=Bluetooth OBEX service

[Service]
Type=dbus
BusName=org.bluez.obex
ExecStart=/usr/lib/bluetooth/obexd --root=/opt/bluetooth

[Install]
Alias=dbus-org.bluez.obex.service

Further documentation for installing, configuring and troubleshooting bluetooth can be found by consulting the Arch Wiki.

Troubleshooting

Firstly, check the logs. A frequent issue is that the kernel is unable to locate the firmware for the device during system boot. Use the egrep utility to search system message for items starting with blue or firm.

dmesg | egrep -i 'blue|firm'

If there is a problem locating the firmware file, then a message should be logged indicating that a hcd file could not be found or patched. If this is the case then the following actions can be taken:

1. Firstly, determine the vendor and product ID for the bluetooth device. This will be useful when searching online forums and resources for the correct firmware required. Furthermore, the vendor and product ID is required if it is necessary to convert a Microsoft Windows Broadcom driver to a format that Linux uses. Type lsusb to list usb devices. Alternatively, use lspci -vnn if the bluetooth device is a pci card. Take a note of the device and product ID for the bluetooth device. Both utilities list devices in the format vendor id:product id.
2. The kernel locates firmware from a predefined location. Arch Linux ARM stores firmware within the /lib/firmware folder. If the firmware file cannot be located, an error message will be logged in the output of dmesg. Refer to these logs to determine the correct firmware file and expected location.
3. Search the Arch Linux forums and AUR to determine if there is a firmware package for the bluetooth device and install using pacman. This will install the required firmware at the expected location.
4. Alternatively, if the device uses a Broadcom chipset then the hex2hcd utility can be used to convert the Microsoft Windows driver to the hcd firmware format, required by Linux. Subsequently, download and extract the Microsoft Windows driver for the bluetooth device. Locate the inf within the extracted folder. Search the file for the section that references the product code for the bluetooth device. This section should reference a hex firmware file. For example, the author has an Asus Bt-400 bluetooth device. The lsusb utility shows that this has a vendor ID of 0b05 and a product ID of 17cb. An extract from the Microsoft Windows driver inf file is shown below for this product code. It can be seen that this device requires hex file, BCM20702A1_001.002.014.1443.1467.hex. This is a hexadecimal file that contains the binary instructions and data necessary to configure and initialise the bluetooth device during system boot. This file must be converted to the hcd firmware format required by Linux.

    

    ;;;;;;;;;;;;;RAMUSB17CB;;;;;;;;;;;;;;;;; [RAMUSB17CB.CopyList] bcbtums.sys btwampfl.sys BCM20702A1_001.002.014.1443.1467.hex ... ... [RAMUSB17CB.NTx86.hw.reg] HKR,,LowerFilters, 0x00010000, "bcbtums" HKR,,%RAMPatchFileName%,0x00000, "BCM20702A1_001.002.014.1443.1467.hex" HKR,,%RemoteWakeEnabled%,0x00010001,1 HKR,,%DeviceRemoteWakeSupported%,0x00010001,1 

   Locate the hex file in the windows driver folder, downloaded and extracted earlier. Convert the file using the hex2hdc utility. An example is listed below for the BCM20702A1_001.002.014.1443.1467.hex file from the example above.

    hex2hcd BCM20702A1_001.002.014.1443.1467.hex -o BCM20702A1-0b05-17cb.hcd 

   
   Upon inspecting the output of dmesg the kernel expects a firmware file named, BCM20702A1-0b05-17cb.hcd to be located in at /lib/firmware/brcm folder. Use the -o switch of the hex2hcd utility to specify the name of the converted file. Finally, copy the converted firmware file to the location, expected by the kernel.

    sudo cp BCM20702A1-0b05-17cb.hcd /lib/firmware/brcm/ 

   
   Finally, shutdown the Raspberry Pi and disconnect the power. Power off USB hub and power on again. Power on the Raspberry Pi again and check the system logs, using dmesg, to check that firmware has been loaded.

Conclusion

This article has summarised experiences for configuring bluetooth on Arch Linux ARM, for Raspberry Pi. Prerequisite packages have been outlined and a brief overview of the bluetooth management utility, bluetoothctl, has been provided. Furthermore, usage of the obexftp utility, for sending and receiving files, with a bluetooth connection was briefly explained, in addition to the obex daemon. Finally, the article concluded with an explanation of troubleshooting bluetooth firmware.

Further documentation for installing, configuring and troubleshooting bluetooth can be found by consulting the Arch Wiki.