Have been testing a Bluetooth 2.1 keyboard, but we don't get any
keypress notifications from it as the pincode is typed and the Agent's
DisplayPasskey D-Bus method is never called (with two or three
arguments).
Any ideas where to begin debugging this?
Scott
--
Scott James Remnant?|?Chrome OS Systems?|[email protected]?|?Google
On Mon, Jan 9, 2012 at 12:16 PM, Marcel Holtmann <[email protected]> wrot=
e:
> > Right now it looks like it's just making a connection to the HID
> > Interrupt PSM (0x13), and while that connection is open, seeing the
> > keypresses.
> >
> > Is there an L2CAP debugger on the Linux side, so I can make sure I'm
> > replicating what it's doing packetwise?
>
> hcidump can record binary logfiles with -w. If you use hcidump 2.x then
> it automatically record into BTSnoop format. Supported by Wireshark as
> well. You can also use -R to see the raw data packets.
>
Ok, so here's what's happening:
When it sees that it's pairing with an Apple keyboard, OS X makes an
L2CAP connection to the HID Interrupt PSM (0x13) between the initial
connection to the keyboard and the authentication request.
This connection receives a notification every time a key is pressed
(any key, OS X doesn't care, it moves along to the next).
Once authentication is complete, OS X drops this L2CAP connection
Scott
--
Scott James Remnant=A0|=A0Chrome OS Systems=A0|[email protected]=A0|=A0G=
oogle
Hi Scott,
> >> So it turns out that the Mac isn't doing anything special either; it's
> >> doing ordinary 2.0 authentication. But the twist is an L2CAP
> >> connection and configuration request/response before authentication is
> >> requested, this seems to enable the keyboard sending a Vendor Event
> >> every time a key is pressed during authentication.
> >
> > that is what I thought. Get your Packet Logger in OS X running and hope
> > that it decodes a bit more. However getting this integrated into BlueZ
> > might be a lot trickier. This is nasty stuff.
> >
> Right now it looks like it's just making a connection to the HID
> Interrupt PSM (0x13), and while that connection is open, seeing the
> keypresses.
>
> Is there an L2CAP debugger on the Linux side, so I can make sure I'm
> replicating what it's doing packetwise?
hcidump can record binary logfiles with -w. If you use hcidump 2.x then
it automatically record into BTSnoop format. Supported by Wireshark as
well. You can also use -R to see the raw data packets.
Regards
Marcel
On Mon, Jan 9, 2012 at 11:54 AM, Marcel Holtmann <[email protected]> wrote:
>> So it turns out that the Mac isn't doing anything special either; it's
>> doing ordinary 2.0 authentication. But the twist is an L2CAP
>> connection and configuration request/response before authentication is
>> requested, this seems to enable the keyboard sending a Vendor Event
>> every time a key is pressed during authentication.
>
> that is what I thought. Get your Packet Logger in OS X running and hope
> that it decodes a bit more. However getting this integrated into BlueZ
> might be a lot trickier. This is nasty stuff.
>
Right now it looks like it's just making a connection to the HID
Interrupt PSM (0x13), and while that connection is open, seeing the
keypresses.
Is there an L2CAP debugger on the Linux side, so I can make sure I'm
replicating what it's doing packetwise?
Scott
--
Scott James Remnant?|?Chrome OS Systems?|[email protected]?|?Google
Hi Scott,
> > > >> Have been testing a Bluetooth 2.1 keyboard, but we don't get any
> > > >> keypress notifications from it as the pincode is typed and the Agent's
> > > >> DisplayPasskey D-Bus method is never called (with two or three
> > > >> arguments).
> > > >>
> > > >> Any ideas where to begin debugging this?
> > > >
> > > > first, start with hcidump to see what commands and events are actually
> > > > send by the keyboard. And capture the bluetoothd debug output.
> > > >
> > > > And I am pretty sure that a real 2.1 keyboard with Secure Simple Pairing
> > > > is not working at all. We never managed to purchase one of these. If you
> > > > managed to find one, then let us know where you got it from.
> > > >
> > > I have both of those attached, the keyboard is the Apple Wireless
> > > Keyboard - it at least behaves in a manner consistent with 2.1 SSP
> > > under OS X, complete with hilighting the passkey as it's typed.
> > >
> > > One thing I noticed from the log is that neither side exchanges IO
> > > capabilities which seems to be a pre-requisite for SSP?
> >
> > you are correct here and the usage of PIN Code Request makes it clear
> > that this is 2.0 only keyboard. Can you create a binary dump in BTSnoop
> > format. Since I see a bunch of vendor events, maybe that is how OS X
> > does it.
> >
> Yup, sending by hand a Remote Version command means the keyboard does
> admit that it's 2.0 not 2.1, so the only devices we can find that are
> 2.1 are the host controllers in all of the hosts :-)
>
> > That said, since this is 2.0 without SSP, it should actually work. Have
> > you tried to use simple-agent test script from the source?
> >
> Pairing works, it's just ugly compared to OS X with it's pretty
> light-as-you-type stuff, and you know how those UI designers are ...
>
>
> So it turns out that the Mac isn't doing anything special either; it's
> doing ordinary 2.0 authentication. But the twist is an L2CAP
> connection and configuration request/response before authentication is
> requested, this seems to enable the keyboard sending a Vendor Event
> every time a key is pressed during authentication.
that is what I thought. Get your Packet Logger in OS X running and hope
that it decodes a bit more. However getting this integrated into BlueZ
might be a lot trickier. This is nasty stuff.
Regards
Marcel
On Fri, Jan 6, 2012 at 5:40 PM, Marcel Holtmann <[email protected]> wrote=
:
Thanks for the pointers!
> > >> Have been testing a Bluetooth 2.1 keyboard, but we don't get any
> > >> keypress notifications from it as the pincode is typed and the Agent=
's
> > >> DisplayPasskey D-Bus method is never called (with two or three
> > >> arguments).
> > >>
> > >> Any ideas where to begin debugging this?
> > >
> > > first, start with hcidump to see what commands and events are actuall=
y
> > > send by the keyboard. And capture the bluetoothd debug output.
> > >
> > > And I am pretty sure that a real 2.1 keyboard with Secure Simple Pair=
ing
> > > is not working at all. We never managed to purchase one of these. If =
you
> > > managed to find one, then let us know where you got it from.
> > >
> > I have both of those attached, the keyboard is the Apple Wireless
> > Keyboard - it at least behaves in a manner consistent with 2.1 SSP
> > under OS X, complete with hilighting the passkey as it's typed.
> >
> > One thing I noticed from the log is that neither side exchanges IO
> > capabilities which seems to be a pre-requisite for SSP?
>
> you are correct here and the usage of PIN Code Request makes it clear
> that this is 2.0 only keyboard. Can you create a binary dump in BTSnoop
> format. Since I see a bunch of vendor events, maybe that is how OS X
> does it.
>
Yup, sending by hand a Remote Version command means the keyboard does
admit that it's 2.0 not 2.1, so the only devices we can find that are
2.1 are the host controllers in all of the hosts :-)
> That said, since this is 2.0 without SSP, it should actually work. Have
> you tried to use simple-agent test script from the source?
>
Pairing works, it's just ugly compared to OS X with it's pretty
light-as-you-type stuff, and you know how those UI designers are ...
So it turns out that the Mac isn't doing anything special either; it's
doing ordinary 2.0 authentication. But the twist is an L2CAP
connection and configuration request/response before authentication is
requested, this seems to enable the keyboard sending a Vendor Event
every time a key is pressed during authentication.
Investigating that now
Scott
--
Scott James Remnant=A0|=A0Chrome OS Systems=A0|[email protected]=A0|=A0G=
oogle
Hi Scott,
> >> Have been testing a Bluetooth 2.1 keyboard, but we don't get any
> >> keypress notifications from it as the pincode is typed and the Agent's
> >> DisplayPasskey D-Bus method is never called (with two or three
> >> arguments).
> >>
> >> Any ideas where to begin debugging this?
> >
> > first, start with hcidump to see what commands and events are actually
> > send by the keyboard. And capture the bluetoothd debug output.
> >
> > And I am pretty sure that a real 2.1 keyboard with Secure Simple Pairing
> > is not working at all. We never managed to purchase one of these. If you
> > managed to find one, then let us know where you got it from.
> >
> I have both of those attached, the keyboard is the Apple Wireless
> Keyboard - it at least behaves in a manner consistent with 2.1 SSP
> under OS X, complete with hilighting the passkey as it's typed.
>
> One thing I noticed from the log is that neither side exchanges IO
> capabilities which seems to be a pre-requisite for SSP?
you are correct here and the usage of PIN Code Request makes it clear
that this is 2.0 only keyboard. Can you create a binary dump in BTSnoop
format. Since I see a bunch of vendor events, maybe that is how OS X
does it.
In addition OS X comes with a tool called Packet Logger (from the SDK)
which allows you also to create a dump file. hcidump can actually read
these as well. So having that one to compare would be nice.
That said, since this is 2.0 without SSP, it should actually work. Have
you tried to use simple-agent test script from the source?
Regards
Marcel
On Fri, Jan 6, 2012 at 3:48 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Scott,
>
Hey Marcel, good to hear from you.
>> Have been testing a Bluetooth 2.1 keyboard, but we don't get any
>> keypress notifications from it as the pincode is typed and the Agent's
>> DisplayPasskey D-Bus method is never called (with two or three
>> arguments).
>>
>> Any ideas where to begin debugging this?
>
> first, start with hcidump to see what commands and events are actually
> send by the keyboard. And capture the bluetoothd debug output.
>
> And I am pretty sure that a real 2.1 keyboard with Secure Simple Pairing
> is not working at all. We never managed to purchase one of these. If you
> managed to find one, then let us know where you got it from.
>
I have both of those attached, the keyboard is the Apple Wireless
Keyboard - it at least behaves in a manner consistent with 2.1 SSP
under OS X, complete with hilighting the passkey as it's typed.
One thing I noticed from the log is that neither side exchanges IO
capabilities which seems to be a pre-requisite for SSP?
Scott
--
Scott James Remnant?|?Chrome OS Systems?|[email protected]?|?Google
Hi Scott,
> Have been testing a Bluetooth 2.1 keyboard, but we don't get any
> keypress notifications from it as the pincode is typed and the Agent's
> DisplayPasskey D-Bus method is never called (with two or three
> arguments).
>
> Any ideas where to begin debugging this?
first, start with hcidump to see what commands and events are actually
send by the keyboard. And capture the bluetoothd debug output.
And I am pretty sure that a real 2.1 keyboard with Secure Simple Pairing
is not working at all. We never managed to purchase one of these. If you
managed to find one, then let us know where you got it from.
Regards
Marcel