Arch Linux

PBS

Member

Registered: 2015-06-28

Posts: 53

sdptool is broken in Bluez 5

I would like to discuss the packaging of bluez and bluez-utils, since the move to Bluez 5 has broken various commandline utilities, such as sdptool. For example (same as in this question),

$ sdptool browse local
Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory

This is because Bluez 5 deprecated the old C interface which communicates over the socket /var/run/sdp, and this socket no longer exists. The help message from bluetoothd gives the solution:

$ /usr/lib/bluetooth/bluetoothd --help
...
  -C, --compat                Provide deprecated command line interfaces

I apply this as follows

# nano /etc/systemd/system/dbus-org.bluez.service

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

# systemctl daemon-reload
# systemctl restart bluetooth

Needless to say, this edit is reverted every time bluez is updated. Now /var/run/sdp exists, but sdptool is still broken:

$ sdptool browse local
Failed to connect to SDP server on FF:FF:FF:00:00:00: Permission denied

Comparing to Ubuntu (14.04 is still using Bluez 4) we see that the permissions on /var/run/sdp are different, and setting them to

# chmod 777 /var/run/sdp

(not persistent) finally makes sdptool work.

I do not know whether the (rather uncommunicative?) folk at Bluez are aware that they have broken their own code; if so then they haven't fixed it in the last year I've been seeing this problem. But until the programs are ported to the DBus API and are working again, it makes sense to me to change the default configuration of bluetooth in Arch to make the above steps unnecessary. However I am not so sure these steps are even the right ones to fix the problem - owing to the non-persistence across updates, and the security implications of making /var/run/sdp world-writeable. Could the bluez maintainers comment on this?