Re: Permission denied (13) on Samsung WEP475 headset?

[Colin Beckingham <colbec@start.ca>]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

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 bluetoothd
Aug  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 #2: wep475.hci --]
[-- Type: application/octet-stream, Size: 9006 bytes --]