Some recent Bluetooth chipsets from Intel and Broadcom need to run the btattach command in user-space for Bluetooth to be enabled properly (it "attaches" the BT chipset and triggers the loading of the required firmware if needed).

Such an example is the Broadcom BCM43241 rev B5 chipset found on Lenovo ThinkPad 8 tablets which needs the following command # btattach --bredr /dev/ttyS1 -P bcm but this is applicable to many other Bluetooth chipsets connected to an UART controller.

Q: What is the best recommended way to trigger the required btattach command during boot to have Bluetooth enabled automatically?

P.S. The idea would be to contribute such a modification to Linux distributions starting to package the btattach command (like Debian), since right now many recent devices simply don't have Bluetooth working out-of-the-box. This would be especially useful for tablets that have no or few full-size USB ports.

Discussions on the linux-bluetooth mailing list suggested to create a corresponding udev rule, cf. this message.

For the specific chipset mentioned in the question, a simple udev rule looks like this:

$ cat /etc/udev/rules.d/98-bluetooth-attach-broadcom.rule KERNEL=="BCM2E55:00", RUN+="/usr/bin/btattach --bredr /dev/ttyS1 -P bcm"

with BCM2E55:00 being the hardware ACPI identifier of the corresponding Bluetooth chipset, appearing as a child of the ttyS1 device node (visible via sysfs in /sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$). Each ACPI identifier would need to be added in the rule file with the corresponding /dev/ttyS* adapted for each chipset variant.

However, a known limitation of this simple approach is that it only works for a short amount of time, as described here. Indeed, the btattach command gets killed a few seconds/minutes later on. This is a documented behavior of udev:

Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.`

So instead of launching the btattach command directly from the udev rule itself, other options will need to trigger btattach indirectly to make sure it is not killed, for instance via a systemd service potentially.

This simple answer may still be useful in the meantime when doing some first tests, especially to find the right udev rule condition(s).

up vote 0 down vote accepted

A more refined approach consists in creating a udev rule, triggered only when the right hardware is present, to launch the needed btattach command from a systemd service. This is merging the concepts of the 2 earlier answers.

For the specific chipset mentioned in the question, the udev rule looks simply like this:

$ cat /etc/udev/rules.d/99-bluetooth-btattach.rules KERNEL=="BCM2E55:00", RUN+="/bin/systemctl --no-block start btattach-broadcom-ttyS1.service"

with BCM2E55:00 being the hardware ACPI identifier of the corresponding Bluetooth chipset.

The systemd service, compatible only with chipsets appearing as a child of the ttyS1 device node (visible via sysfs in /sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$), can remain very simple like this:

$ cat /etc/systemd/system/btattach-broadcom-ttyS1.service [Unit] Description=Start btattach, needed to enable Bluetooth for some UART-based Bluetooth Broadcom chipsets [Service] Type=simple # A delay is needed, 1s seems enough ExecStartPre=/bin/sleep 1s ExecStart=/usr/bin/btattach --bredr /dev/ttyS1 -P bcm

This systemd service will work as-is for other Broadcom chipsets (hence the -P bcm parameter) appearing as a child of ttys1 (hence the /dev/ttyS1); only the udev rule needs to be completed to include the ACPI identifiers of other chipset variants.

For Broadcom chipsets attaching to a different ttyS* node, another similar systemd service can be created to cover this case (or maybe the right parameters could be shared from the udev rule to the systemd service).

Rebooting the tablet shows that the btattach command is properly executed at boot:

$ ps auxw | grep btattach root 2059 0.0 0.0 6372 720 ? Ss 23:17 0:00 /usr/bin/btattach --bredr /dev/ttyS1 -P bcm

and Bluetooth is actually enabled and working! The Gnome Bluetooth settings does list connected and scanned devices and running $ bluetoothctl from a command line properly shows the controller.

Surprisingly, when removing the initial 1s sleep command used to simply delay the real command, Bluetooth isn't working at all and not properly enabled despite btattach still appearing to be running correctly in the list of background processes.

Not sure to understand what's happening exactly quite yet: there is a timing issue at stake and certainly a required dependency to wait for, before being supposed to launch btattach...

A working approach is to create a hardcoded systemd service looking like this:

$ cat /etc/systemd/system/btattach.service 
[Unit]
Description=Start btattach, needed to enable Bluetooth for some UART-based Bluetooth chipsets
[Service]
Type=simple
\# A delay is needed though, 1s seems enough on my system
ExecStartPre=/bin/sleep 1s
ExecStart=/usr/bin/btattach --bredr /dev/ttyS1 -P bcm
[Install]
WantedBy=multi-user.target`

To enable this new service, run the following command:

# systemctl --system enable btattach

Rebooting the tablet shows that the btattach command is now properly executed at boot:

$ ps auxw | grep btattach
root      2059  0.0  0.0   6372   720 ?        Ss   23:17   0:00 /usr/bin/btattach --bredr /dev/ttyS1 -P bcm

and Bluetooth is actually enabled and working! The Gnome Bluetooth settings does list connected and scanned devices and running $ bluetoothctl from a command line properly shows the controller.

Surprisingly, when removing the initial 1s sleep command used to simply delay the real command, Bluetooth isn't working at all and not properly enabled despite btattach still appearing to be running correctly in the list of background processes.

Not sure to understand what's happening exactly quite yet: there is a timing issue at stake and certainly a required dependency to wait for, before being supposed to launch btattach...

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.