As an asides, despite the notes in hcid.conf (which are innacurate as hell) there is no bluepin, only /bin/bluepincat and /opt/kde3/lib/kdebluetooth/kbluepin.
As well as this, bluepincat has been substantially rewritten in that it now contains:
- Code: Select all
KBLUETOOTHD_RUN=`ps -ea|grep kbluetoothd`
if [ -f /opt/kde3/lib/kdebluetooth/kbluepin \
-a -x /usr/X11R6/lib/sax/tools/testX \
-a "X$KBLUETOOTHD_RUN" != "X" ]; then
/usr/X11R6/lib/sax/tools/testX --fast && \
echo -n "PIN:"
So it appears that someone's tried to marry bluepin and bluepincat and messed it up.
After it checks that kbluetoothd is running, the first bit (for the uninitiated) checks if kbluepin exists, if testX exists and is executable and if $KBLUETOOTHD_RUN doesn't exist (if it does then bluepincat has probably been called by kbluetoothd) in which case it runs testX (which exits if a WM is already running) and kbluepin.
At this point kbluepin then outputs PIN:xxxx (or whatever you've entered) to stdout.
Of course the problem here is, whether or not any of this is done bluepincat then goes and outputs PIN:xxxx (whatever is in /etc/bluetooth/pin).
Another distro, another non-standard usage of a file breaking everything.... and I thought FC2 was bad.
Soooo, I've taken bluepincat out of the equation replacing it with kbluepin in /etc/bluetooth/hcid.conf and pairing was aided by manually kickstarting hcitool (to find the bdaddr) and sdptool (to get it pointing on the right direction).
Currently the situation is that a) pairing needs to be initiated from the client end if it's to stick (although I really need to know why the headset not only disconnects but switches off after about 30 seconds) b) kbluepin is initialised each time a device tries to connect which is just how I want it but c) every time I've tested this with the Nokia 3650 I need to put the PIN in 4 times (Computer, then phone, then phone, then computer) even though the headset only requires it once (on the computer). This might merit further investigation but I've still got the rest of this headset malarkey to figure out with all the rfcomm stuff but that's for another question.