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.
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
