Bugzilla – Bug 106628
Bluetooth PIN don't ask by user
Last modified: 2005-08-29 13:02:13 UTC
1. /bin/bluepincat called in daemon context, not X11 session, because "testX --fast" failed; 2. For architecture x86-64 paths invalid; Probably working verison /bin/bluepincat: !/bin/bash # # simple none interactiv handler for Bluetooth PIN's # /etc/bluetooth/pin must only contain one line with the # PIN code # # if e.g. kbluetoothd is not running, kbluepin throws an error and returns 1 KBLUETOOTHD=${KBLUETOOTHD:-kbluetoothd} KBLUETOOTHD_RUN=`ps -ea|grep $KBLUETOOTHD` KBLUEPIN=${KBLUEPIN:-/opt/kde3/sbin/kbluepin} if [ -x $KBLUEPIN \ -a "X$KBLUETOOTHD_RUN" != "X" ]; then PIN=`$KBLUEPIN` && { case "$PIN" in PIN:*) echo "$PIN" exit 0 ;; esac } fi; echo -n "PIN:" cat /etc/bluetooth/pin
Argl, testX has moved and I didn't notice itj, that's bad. I've adapted the better path for kbluepin. You still need the testX-check, because you might have a running X and kbluetoothd but no access to the display. I'll try to bring the fix into beta3, but it's a little bit late. But at least in beta4 it will be present.
(In reply to comment #1) > You still need the testX-check, because you might have a running X and This not right on my system (arch=x86_64). For example insert next command to /bin/bluepincat: /usr/sbin/testX --fast logger "$0: testX=$?" logger "$0: env=`env`" logger "$0: pwd=`pwd`" logger "$0: ps=$(ps -g $(ps -o sid= -p $$) -o ruser,user,pid,ppid,sid,tty,comm)" Try Search&Trust from mobile. See /var/log/messages: Aug 24 03:23:49 suse10-lpt hcid[3796]: pin_code_request (sba=00:10:60:A9:CD:67, dba=00:01:E3:59:E6:24) Aug 24 03:23:49 suse10-lpt logger: /bin/bluepincat: testX=1 ^FAIL! Aug 24 03:23:49 suse10-lpt logger: /bin/bluepincat: env=PHYSDEVPATH=/devices/pci0000:00/0000:00:10.2/usb3/3-2/3-2:1.0 SUBSYSTEM=bluetooth WERE_ALREADY_HERE=yes DEVPATH=/class/bluetooth/hci0 COLUMNS=80 PATH=/bin:/usr/bin:/usr/local/bin ACTION=add PWD=/ UDEV_LOG=3 LINES=24 UDEVD_EVENT=1 SHLVL=5 PHYSDEVDRIVER=hci_usb INTERFACE=hci0 PHYSDEVBUS=usb SEQNUM=916 _=/usr/bin/env Aug 24 03:23:49 suse10-lpt logger: /bin/bluepincat: pwd=/ Aug 24 03:23:49 suse10-lpt logger: /bin/bluepincat: ps=RUSER USER PID PPID SID TT COMMAND root root 3796 1 3796 ? hcid root root 12324 3796 3796 ? hcid root root 12325 12324 3796 ? bluepincat root root 12335 12325 3796 ? ps Aug 24 03:24:01 suse10-lpt hcid[3796]: link_key_notify (sba=00:10:60:A9:CD:67, dba=00:01:E3:59:E6:24) May be `testX' have bug for x86_64. But we see: parent `hcid' run as `root' and don't set X11/KDE eviroment for `bluepincat'. testX-check MUST fail from `bluepincat'. IMHO, `kbluepin' don't need to communicate with desktop, because testX-check need to remove. > kbluetoothd but no access to the display. hcid/bluepincat/kbluepin/kbluetoothd - have big design problem for fasr user switching. For example, if we have two desktop session ((:0, vt7) & (:1, vt8)), PIN code will be asked only on one desktop. But this problem out scope this bug. Sorry for my best English
No problem. Since we have a little bit time until beta4 deadline, I'll take a closer look at it as soon as my 64bit-machine is back. Regarding your last paragraph with the two desktop sessions: Yes, that's correct. There has been a lot of work done to include D-BUS-support in the bluetooth-system, but that is not finished yet. Maybe we will see a solution with D-BUS for that problem.
Strange. I can reproduce it here with the x64 but not on the 32bit machine. I'll adapt your version, it shouldn't break anything. I'll mention you in bluepincat if you permit. beta4 contains the fixed package.
Ok, checked into STABLE.