Bug 212825 - bluez pairing fails
bluez pairing fails
Status: CLOSED DUPLICATE of bug 212421
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Depends On:
  Show dependency treegraph
Reported: 2006-10-29 07:50 EST by Mikhail Lukachev
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-21 08:15:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mikhail Lukachev 2006-10-29 07:50:15 EST
Description of problem:

pairing with other bluetooth devices (phone and headset) fails.

Version-Release number of selected component (if applicable):


How reproducible:


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,
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.
Comment 1 David Woodhouse 2006-10-29 08:33:24 EST
You shouldn't have bluez-pin installed; you should have bluez-gnome. Make sure
the bluetooth-applet is running
Comment 2 Mikhail Lukachev 2006-10-30 05:25:31 EST
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.
Comment 3 Jonathan Rawle 2006-11-04 13:52:13 EST
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.
Comment 4 Doug Palmer 2007-02-20 21:05:28 EST
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.
Comment 5 David Woodhouse 2007-02-22 22:28:37 EST
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.
Comment 6 Douglas E. Warner 2007-02-22 22:33:39 EST
Yes; bluetooth-applet works, but there's no way to assign the default pin 
program to kbluepin without passkey-agent.
Comment 7 Claus Olesen 2007-03-29 05:00:11 EDT
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) 

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").
Comment 8 John Floyd 2007-05-13 21:04:50 EDT
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.
Comment 9 David Woodhouse 2007-07-21 08:14:32 EDT
This is effectively a duplicate of bug #212421
Comment 10 David Woodhouse 2007-07-21 08:15:01 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.