On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote: > But nothing seems to enable the pairing, and everytime I do that that far in > the 'bluetooth-wizard' and it sees the eb101, it tells me to enter an > apparently randomly derived 4 digit pin number, but the wizard gives me no > place to enter it. Nor is there a 'proceed' button, and in 5 seconds or so it > clears that screen and reports pairing failed. bluez-gnome (where your bluetooth-wizard comes from?) has a really stupid UI design. If bluetooth-wizard thinks you *can* enter a PIN into your device, it will *require* you to enter a random one. This idea doesn't work so well on devices that don't have keyboards or that have fixed PINs, and bluetooth-wizard knows only about broad categories of devices and a handful of exceptions. The opposite problem occurs on devices where bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually doesn't. Also, bluez-gnome's discovery page won't show you discoverable devices that are already known, so it can't tell you if a known device is in range. 'hcitool scan' will tell you about all devices in range, but it causes some problems for bluetoothd if both are running at the same time. If you can, use simple-agent instead of bluetooth-wizard. > Aha! A chance comment I read someplace paid off! I knew the PIN code for > that device was 0000 after a factory reset, which had been done several times. > The comment was that if a pairing failed, they had to be powered off before it > could be tried again, so I went to the other end and did a powerdown reset, > than came backup up to here and swapped one for the other of the 2 devices I > had here, which have identical bdaddr's. How do you have two devices with identical bdaddr's? Doesn't that wreak all sorts of havoc for a piconet? I would expect it to make all the link key management stop working, since link keys are randomly generated on each device, but stored in a database keyed by bdaddr. Also, the piconet master clock for radio frequency hopping is keyed off the master's bdaddr, and has to be unique for each piconet. > Then I ran > [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8 > RequestPinCode (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8) > Enter PIN Code: 0000 > Release > New device (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8) > > Ok, tapped the hdwe reset on the coco3 and let it reboot which restarts the > shell I killed that should be available for minicom to talk to.. So at this point you should have a link key established between your Bluetooth devices. You have successfully completed pairing, and if the remote device has non-volatile storage, it will stay paired. Normal remote devices do have non-volatile storage for link keys, but I'm not sure your devices are normal. > Operative word is 'should': > [root@coyote test]# minicom > minicom: cannot open /dev/rfcomm0: No such file or directory > [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8 > Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists Yep, still paired...at least on the BlueZ side. > [root@coyote test]# rfcomm release all > [root@coyote test]# rfcomm bind 0 00:0c:84:00:86:F8 I think this creates a device file named "0". Try "/dev/rfcomm0" instead. Also make sure that /dev/rfcomm0 exists after you've finished rfcomm bind. If you're using udev (which all modern distros should be), this should happen automatically after binding. If it doesn't, you can try "MAKEDEV rfcomm0" or "mknod /dev/rfcomm0 c 216 0". > [root@coyote test]# minicom > minicom: cannot open /dev/rfcomm0: No such file or directory > > I think I'm battling with a bad error message that isn't telling me what I > think it is. No, in this case it's probably telling you that /dev/rfcomm0 really doesn't exist. *Why* it doesn't exist is a separate question. ;) > [root@coyote test]# rfcomm connect 0 00:0c:84:00:86:F8 1 > Can't connect RFCOMM socket: Host is down This usually means your remote device isn't connectable, or out of range, or has turned itself off, or has crashed, or maybe some other device has connected to the device you're trying to connect to. Apparently it can also mean the device isn't paired...or at least I get the same error when trying to bind rfcomm sockets to unpaired devices. So maybe you're not so paired after all. It should be /dev/rfcomm0, not just 0, I think. > [root@coyote test]# sdptool browse 00:0c:84:00:86:F8 > Failed to connect to SDP server on 00:0C:84:00:86:F8: Host is down > > So what is the real problem here other than I'm a clueless newbie? It looks like your remote device is pairable, but maybe requires some kind of magic button sequence to make it connectable. That would be odd, but within the realm of possibility. Or, your Bluetooth adapter hangs right after pairing. That would also be odd, but possible. There would probably be kernel log messages in that case at around the time it fails. Also, 'hciconfig hci0 reset' might help if this is the case. Another thing to watch out for is that a few devices like to power themselves off if nothing is connected to them for some time. I have a headset that does this, which pretty much guarantees I'll never receive a phone call with it. Or possibly you have two devices with identical bdaddr, and they're both turned on at the same time, or you've paired with one and are now trying to connect to the other. > Did that: > [root@coyote test]# rfcomm release all > [root@coyote test]# rfcomm bind /dev/rfcomm0 00:0C:84:00:86:F8 1 [...] > Terminal programs such as minicom cannot connect to /dev/rfcomm0, claiming it > does not exist. > root@coyote test]# ls -l /dev/rfcomm* > crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0 > [root@coyote test]# minicom > minicom: cannot open /dev/rfcomm0: No such file or directory > > Next? You seem to have paired successfully, but can't get any connections to work afterwards. Maybe try 'l2ping' to verify the remote device is still on?
Attachment:
signature.asc
Description: Digital signature
