Attempting to connect a bluetooth device (a no-name GPS device which presents a serial interface) fails: 1. Run the bluetooth wizard. 2. Select the device and select 'next'. 3. The wizard displays 'Connecting to GPS-GW-005' 4. A message along the lines of 'please enter ....' flashes up very briefly. 5. The wizard displays 'Pairing with GPS-GW-005 failed'.
Hacking the source code to hardwire the passcode, got the device connected OK. So bug is that bluetooth-wizard assumes it can always choose an arbitrary passcode. It can't; it needs to let the user input the passcode, as it may be hardwired into the device. I guess this bug should go upstream, but I can't find an upstream bugzilla. Any hints/ the www.bluez.org website doesn't list any contacts for the user-space stuff.
Use the mailing-list on vger.kernel.org. It's probably using the hard-coded "0000" pincode as the device also offers a headset functionality.
Could you let me know the output of: sdptool browse <bluetooth address> when the device is ready to pair, as well as the pin code you used to configure it (I guess 0000 ?).
sdptool gives not very much: $ sdptool browse 00:0D:B5:38:37:56 Browsing 00:0D:B5:38:37:56 ... and exits. The pin is indeed 0000.
Could you please try getting the output of "hcitool info <bluetooth address>", as well as "sdptool search --bdaddr <bluetooth address> SP"?
$ hcitool info 00:0D:B5:38:37:56 Requesting information ... BD Address: 00:0D:B5:38:37:56 OUI Company: GLOBALSAT TECHNOLOGY CORPORATION (00-0D-B5) Device Name: BT-GPS-383756 LMP Version: 1.2 (0x2) LMP Subversion: 0x8ce Manufacturer: Cambridge Silicon Radio (10) Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80 <3-slot packets> <5-slot packets> <encryption> <slot offset> <timing accuracy> <role switch> <hold mode> <sniff mode> <park state> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme> <power control> <transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan> <interlaced pscan> <inquiry with RSSI> <extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave> <AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL> <AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features> $ sdptool search --bdaddr 00:0D:B5:38:37:56 SP Searching for SP on 00:0D:B5:38:37:56 ... Service Name: BT-GPS COM Port Service RecHandle: 0x10000 Service Class ID List: "Serial Port" (0x1101) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Language Base Attr List: code_ISO639: 0x656e encoding: 0x6a base_offset: 0x100
I finally received the hardware to test this. Should have something to report tomorrow.
Please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=899542 If it doesn't work, please provide the full output of "hcitool scan" redirected to a file (so that no data is lost) when the GPS device is discoverable.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed in the errata: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11419