Hi Peter: On 08/06/2011 10:36 AM, Peter Hurley wrote:
On Thu, 2011-08-04 at 10:54 -0400, Peter Hurley wrote:Hi Colin, On Thu, 2011-08-04 at 08:17 -0400, Johan Hedberg wrote:Hi Colin, On Thu, Aug 04, 2011, Colin Beckingham wrote:I'd like to provide some feedback regarding a Samsung WEP475 headset which fails to connect to linux specifically. The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1 Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475 successfully connects to a Windows XP machine and to the Nokia E71. Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails with 2.6.38), bluez 4.96 and bluedevil manager. Symptoms are that bluedevil sees the headset in pairing mode and correctly retrieves the name WEP475, connected button flashes green and then returns to grey (not connected). WEP475 led changes to connected status but bluedevil shows headset not connected and headset does not work. With bluetoothd in debug mode, I get the following transactions in /var/log/messages:There seems to be something strange going on with the secure simple pairing logic. For some reason the initial link key isn't good enough (auth request + link key negative reply after the initial key has been generated) and then there's a user confirm negative reply for the second attempt. It'd be good to get to the bottom of this and fix it properly, but meanwhile you can probably work around this by disabling SSP on your side (hciconfig hci0 sspmode 0) and retrying pairing.You're having this problem because the remote device supports SSP but not MITM protection. Some socket is requiring BT_SECURITY_HIGH (thus requiring MITM) -- therefore the kernel is correctly disconnecting and returning 'Authentication Failure' (although returning 'Insufficient Authentication' would probably be better). I think the GATT browser is demanding BT_SECURITY_HIGH -- not sure why though (I don't think it needs to. I'll get back to you on that...)Colin- Well, I was wrong about it being related to GATT. I can see some other possibilities but I'm confused by the syslog relative to the bt capture (eg., the syslog clearly shows a found key but the hcidump shows link key negative reply). Were they taken at the same time?! Regards, Peter PS - If you do send another hcidump, please send a binary capture (with timestamps) as you have an old version of hcidump that doesn't decode not-automatically-flushable l2cap packets.
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.I downloaded and installed the latest hcidump which identifies itself (hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog # tail -n 100 /var/log/messages | grep bluetoothdAug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got disconnected Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote device can't provide MITM Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session 0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13) and a binary hcidump is attached. -- --- Colin Beckingham
Attachment:
wep475.hci
Description: Binary data
