Red Hat Bugzilla – Bug 212825
bluez pairing fails
Last modified: 2007-11-30 17:11:47 EST
Description of problem: pairing with other bluetooth devices (phone and headset) fails. Version-Release number of selected component (if applicable): bluez-utils-3.7-2 bluez-pin-0.30-5 How reproducible: always Steps to Reproduce: 1. enable bluetooth on both computer and phone; 2. connect the RFCOMM device to the remote bluetooth device in explicit (rfcomm connect hci0 00:11:9F:79:A0:2B 1) or via minicom (when /dev/modem is the symbolic link to /dev/rfcomm0) or in implict way (pppd call callscript). Actual results: phone asks to type a passcode for computer and then pairing fails (no link_key file is created). Expected results: phone asks to type a passcode for computer and then computer should ask a passcode for the phone and then a pairing is complete (the link_key file is created). we can query a modem via minicom or make gprs connection to internet (pppd call callscript). Additional info: rfcomm connect hci0 00:11:9F:79:A0:2B 1 and after asking for the passcode -- Can't connect RFCOMM socket: Connection refused in /var/log/messages we see Oct 29 14:29:14 smalltux hcid[2666]: pin_code_request (sba=00:20:E0:4A:AC:A1, dba=00:11:9F:79:A0:2B) but no popup window appears for the passcode on the computer ("xhost +" was typed already). In addition, we see that a new version bluez daemon does not like a pin_helper option: "Oct 29 14:15:52 smalltux hcid[2666]: Unknown option 'pin_helper' line 24" trying to run /usr/bin/bluez-pin also does not help. the same result when connecting a bluetooth headset. the option "passkey" in hcid.conf is also not useful. In FC4 everything worked fine.
You shouldn't have bluez-pin installed; you should have bluez-gnome. Make sure the bluetooth-applet is running
Here is an additional information I obtained after some testing: The Fedora Core 6 ships in release with the following packages: bluez-utils-2.25-12 (that contains bluepin) and bluez-pin-0.30-5 as dependent package. There is already an update for bluez-utils to verison 3.7-2 which also replaces bluez-pin with bluez-gnome. Users who install bluez-utils via internet with yum obtain the updated bluez-utils-3.7-2 (and bluez-gnome). I did not get a pairing with updated bluez-utils-3.7-2. The /var/log/messages file shows "pin_code_request", but no popup appears (bluetooth-applet is running). Some things are definitely broken in new version. I supposed that probably the version before update works and discovered that it is 2.x version of bluez-utils which makes an initial pairing successful. After an update things seem working (because the initial pairing was already done and linkkeys file exists). So there could be still trouble for making *initial* pairing with bluez-utils-3.7-2.
The bluez-utils package is missing the passkey-agent binary. This can be used, for example: passkey-agent --default 1234 allows pairing using the PIN entered. If you download and compile the SRPM, this binary can be found in bluez-utils-3.7/hcid. This should be included in the bluez-utils RPM so that it is installed along with the rest of bluez. It would allow easier debugging, and also enable KDE users to pair their devices. It's the only way I've been able to get bluetooth working on my FC6 installation.
Part of the problem seems to be that the bluetooth-applet, which substitutes for passkey-agent, is invisible to KDE users. Once I got it running on the command line, things started to pair properly.
The bluetooth applet works fine under KDE; I tested it. I also filed a bug for the fact that KDE doesn't honour the startup .desktop file.
Yes; bluetooth-applet works, but there's no way to assign the default pin program to kbluepin without passkey-agent.
Thank you for the this error report. I want to elaborate a little because I spent a lot of time struggling with this and I'm likely not the only one. I tried various pin_helper options, the passkey-agent, old as well as a new bluez rpms and self-built packages, removed /var/lib/bluetooth/*, tinkered with every option in /etc/bluetooth/* config files, etc... but kept getting connection refused. And hcidump and /var/log/messages confirmed but did not otherwise help (me) much. I use KDE, knew about the bluetooth-applet but was sure it would take gnome to run it and I don't have gnome installed. So - thank you for the tip about running the bluetooth-applet from the command line in KDE. What I did is 1. from a konsole, kill the resident bluetooth-applet # killall bluetooth-applet 2. next, enter the command # bluetooth-applet It returned the following messages libnotify-Message: Unable to get session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. but did not exit. 3. in another konsole, bind the bluetooth device (mine is GPS sensor) # rfcomm bind /dev/rfcomm0 nn:nn:nn:nn:nn:nn 1 4. next, post a read for data from the bluetooth device # cat < /dev/rfcomm0 Perhaps at this point the bluetooth-applet GUI should have popped up by itself. Mine didn't but the tray icon was flashing. I clicked a couple of times on the tray icon - and then the GUI popped up. I entered the pin in the GUI and... data then started flowing from the bluetooth GPS device! At this point the konsole from where the bluetooth-applet was run showed several instances of this message ** (bluetooth-applet:4074): CRITICAL **: dbus_g_proxy_connect_signal: assertion `DBUS_IS_G_PROXY (proxy)' failed I then rebooted, repeated and learned that everything still works. And that the pin need not again be entered (I see a long number in /var/lib/bluetooth/linkkeys - perhaps that's the "substitute").
One ploblem with the applet approach - I am using bluetooth through rfcomm for interfacing to GPS and echo sounders, I do not want or need gui popups for setting passkeys! I cannot afford to fill in a gui dialog everytime I start the logger program for each bluetooth device that is attached and used by the program. Under the old previous system my pin-helper had passkeys defined for each device (could be different for each device) in my customised python pin-helper code (could also query a datbase/file, and create a popup if that device isnt in the database, with options to store it if necessary). Please do not aim everything at gui's they are not always appropriate.
This is effectively a duplicate of bug #212421
This is effectively a duplicate of bug #212421 *** This bug has been marked as a duplicate of 212421 *** *** This bug has been marked as a duplicate of 212421 ***