I had some trouble with bluetooth devices lately, now i tracked it to the cause of it. Kernel Bluetooth + bluez does work as advertised. Using the builtin agent & bluetoothctl command i was able to discover, pair and trust & access BT devices. All while bluedevil just says that devices are off, and system settings reports there are no devices. After adding the following to the /etc/dbus-1/system.d/bluetooth.conf <policy group="users"> <allow own="org.bluez"/> <allow send_destination="org.bluez"/> <allow send_type="method_call"/> <allow send_interface="org.bluez"/> <allow send_interface="org.bluez.Agent"/> <allow send_interface="org.bluez.Get"/> <allow send_interface="org.bluez.PasskeyAgent"/> <allow send_interface="org.bluez.Adapter1"/> <allow send_interface="org.bluez.Device1"/> <allow send_interface="org.bluez.AgentManager1"/> <allow send_interface="org.bluez.Agent1"/> <allow send_interface="org.bluez.MediaEndpoint1"/> <allow send_interface="org.bluez.MediaPlayer1"/> <allow send_interface="org.bluez.ThermometerWatcher1"/> <allow send_interface="org.bluez.AlertAgent1"/> <allow send_interface="org.bluez.Profile1"/> <allow send_interface="org.bluez.HeartRateWatcher1"/> <allow send_interface="org.bluez.CyclingSpeedWatcher1"/> <allow send_interface="org.bluez.GattCharacteristic1"/> <allow send_interface="org.bluez.GattDescriptor1"/> <allow send_interface="org.freedesktop.DBus.ObjectManager"/> <allow send_interface="org.freedesktop.DBus.Properties"/> </policy> (the addition is access for the users group. copy from root...) So appearantly the default bluetooth.conf for dbus doesn't workout on notebooks. Without the above rules: no access and messages in logfiles like: Feb 05 18:18:24 [dbus] [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.63" (uid=2000 pid=16224 comm="bluedevil-monolithic ") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=4703 comm="/usr/libexec/bluetooth/bluetoothd ") Feb 05 18:18:25 [dbus] [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.64" (uid=2000 pid=16271 comm="/usr/bin/systemsettings -caption System Settings -") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=4703 comm="/usr/libexec/bluetooth/bluetoothd ")
Same problem here, I have consolekit installed but not systemd. The user is not part of plugdev group.
What dbus version are you running? Can you try with dbus-1.10.8-r1 and user-session USE flag *disabled* (and after rebooting with that)
This is installed: [I] sys-apps/dbus Available versions: 1.8.16 ~1.8.20 1.10.6^t ~1.10.8-r1^t {X debug doc selinux static-libs systemd test user-session ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 1.10.6^t(00:00:15 07-03-16)(X -debug -doc -selinux -static-libs -systemd -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32") Homepage: http://dbus.freedesktop.org/ Description: A message bus system, a simple way for applications to talk to each other
I will try another dbus this week.
Before i try, dbus was forbidding the sessions, so is the set of rules included in the new dbus set or does bluedevil or bluez add them or has the security feature been removed from the set. (so which version of those is then needed?). I have the set of rules from an other distro, so obviously something is needed. imho the bluez kit should add those rules during installation.
Try with the default dbus rules without changing them. Allow all people in users group to play with bluetooth is probably hiding the problem
The original error messages were shown in the the First Post (near the bottom). What should i look for in error messages?
What I expect it to get it working again without issues once you update to dbus-1.10.8-r1 with user-session USE disabled. The user-session way of launching dbus is probably causing all this permission issues
Ok i can confirm this works, bluez & bluedevil needed a recompile as well. bluez to reset the original dbus rules bluedevil because there have been changes in KDE lately that probably were incompatible.
Nico: Are you running OpenRC or systemd?
I run OpenRC.
What is the happening with dbus-1.10.8-r1 without user-session enabled, bluez-5.39 and after rebooting and without changing any upstream config file?
The below combination works. [I] net-wireless/bluez Installed versions: 5.37(17:24:34 04-04-16)(cups doc extra-tools obex readline test-programs udev -debug -selinux -systemd -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" PYTHON_TARGETS="python2_7") Homepage: http://www.bluez.org Description: Bluetooth Tools and System Daemons for Linux [I] sys-apps/dbus Installed versions: 1.10.8-r1^t(14:37:38 04-04-16)(X -debug -doc -selinux -static-libs -systemd -test -user-session ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32") Homepage: https://dbus.freedesktop.org/ Description: A message bus system, a simple way for applications to talk to each other Or was this meant as a request to try bluez-5.39?
Unblocking 576028; user-session is only relevant in a systemd environment.
so user-session will be made dependant on systemd then? and illegal on non-systemd systems?
(In reply to Nico Baggus from comment #15) > so user-session will be made dependant on systemd then? > and illegal on non-systemd systems? It already has no effect on non-systemd systems. A REQUIRED_USE check is unnecessary.
I wouldn't say it has no influence... on non-systemd systems... it totally blocks bluez from being accessible from f.e. bluedevil... that is what started this issue ... i run non-systemd.
user-session is a red herring in this bug report. Your issue was likely solved by rebuilding several other packages. I am certain that user-session had NOTHING to do with it.
It was a flag that was set on dbus that was built at the time. I did build the dbus as requested in comment #2 and did rebuild the bluez & bluedevil to restore the config files supplied by them. (Before the dbus reinstall , when dbus 1.10.6 was enabled, both bluedevil & bluez had been rebuild just to be sure. (see comment #3 on what was installed). Bluez did work with all the commandline tools though. So bluetooth was partly usable, just not from kde based tooling. (even without the dbus policies) And i needed the adjustment to the dbus policies supplied in the description to get stuff to work. If that was a red-herring so be it.... no policies ==> no bluetooth from bluedevil.. So before issuing the bug report, i had already checked & tested my configuration. I meant this bug report as a notice that something in the upgrade of dbus appearantly broke something else some time before (I don't access my latop from my phone that often). And that to get bluedevil working again a dbus policy change was needed. (or as it was appearantly needed a dbus 1.10.8-r1 rebuild WITHOUT user-session).
According to comment #13 the reported problem is gone. I am changing the solution type to "OBSOLETE" to get this bug out of the "NEEDINFO" bug list which will help us to track bugs where people submitted the requested information but forgotten to re-open...
