Failure when starting bluetooth.service

Hello Toradex community,

I have a USB-Bluetooth module embedded on my baseboard. To bring the interface from the DOWN state to the UP state I have the following systemd script:

#bluetooth-up.service
[Unit]
Description=Bluetooth hci0 up
Requires=bluetooth.target
Before=bluetooth.service

[Service]
Type=oneshot
ExecStart = /usr/bin/hciconfig hci0 up
RemainAfterExit=yes

[Install]
WantedBy=bluetooth.target

Additionally, to start the bluez dbus daemon the following is started (this is just the default bluetooth.service config file as shipped by Toradex/Angstrom):

[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluez5/bluetooth/bluetoothd
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service

However when my system boots I get the following:

root@colibri:~# systemctl status bluetooth -l
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2016-05-24 11:59:45 UTC; 6min ago
     Docs: man:bluetoothd(8)
 Main PID: 669 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─669 /usr/lib/bluez5/bluetooth/bluetoothd

May 24 11:59:45 colibri systemd[1]: Starting Bluetooth service...
May 24 11:59:45 colibri bluetoothd[669]: Bluetooth daemon 5.33
May 24 11:59:45 colibri systemd[1]: Started Bluetooth service.
May 24 11:59:45 colibri bluetoothd[669]: Starting SDP server
May 24 11:59:45 colibri bluetoothd[669]: Bluetooth management interface 1.4 initialized
May 24 11:59:45 colibri bluetoothd[669]: Failed to obtain handles for "Service Changed" characteristic
May 24 11:59:45 colibri bluetoothd[669]: hci0 Load Connection Parameters failed: Unknown Command (0x01)

and the Bluetooth interface is brought to DOWN state even though the bluetooth-up script previously managed to bring it up (note that bluetooth-up.service should run before bluetooth.service):

root@colibri:~# hciconfig
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:07:80:06:27:E3  ACL MTU: 310:10  SCO MTU: 64:8
        DOWN
        RX bytes:2046 acl:0 sco:0 events:124 errors:0
        TX bytes:3355 acl:0 sco:0 commands:112 errors:0

My question is twofold:

  • My bluetooth-up.service seems an oddly home-made solution for a rather common problem. Am I going about this the wrong way?
  • Do you know why the errors above appear and do you know how to fix them?

Thank you,
Gardar

To eliminate one possibility, what is the output of

rfkill list

Does it show bluetooth as blocked?

No, bluetooth is not blocked:

root@colibri:~# rfkill list
0: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

Tested a systemd service as per our Autorun article.

#bluetooth-up.service
[Unit]
Description=Bluetooth auto power on
After=multi-user.target 

[Service]
Type=simple
ExecStartPre = /usr/sbin/rfkill unblock all
ExecStart = /usr/bin/hciconfig hci0 up

[Install]
WantedBy=multi-user.target

For my Cambridge Silicon Radio based USB dongle I had to include rfkill unblock without which it does not come up.

root@colibri-imx6:~# lsusb
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

After a boot/reboot

root@colibri-imx6:~# hciconfig
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1A:7D:DA:71:13  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING PSCAN 
        RX bytes:1152 acl:0 sco:0 events:62 errors:0
        TX bytes:1044 acl:0 sco:0 commands:62 errors:0

Hmm, that’s odd. After looking further into this I noticed that the situation immediately after boot (only running the startup scripts I provide above, i.e. no rfkill) is actually that the bluetooth module is in “up” state. If I do a systemctl restart bluetooth the device is brought down though. I’m also using the Cambridge Silicon Radio driver:

root@nox-c1-debug:~# lsusb
Bus 001 Device 003: ID 0a12:0000 Cambridge Silicon Radio, Ltd

So, while my system currently boots with the Bluetooth adapter in the correct state (I’m sorry, when I originally posted I thought the Bluetooth device was down on boot) this does feel a bit fragile. I don’t particularly like errors with unknown effects.

I think we can shelve this for now, I’ll repost to this thread if I find anything further.

This seems to be a common problem with the Linux bluetooth stack, the Arch Linux Wiki also provides some possible work arounds:

https://wiki.archlinux.org/index.php/bluetooth#Configuration_via_the_CLI