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
# 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?