Hello,
Recently, I posted a bug report regarding authentication failures when
pairing with BLE 4.0 devices. I was told to raise this issued to the
Bluetooth mailing lists and I hope this is the correct email to contact.
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822633
Regards and thank you,
You Ren (Joey) Chen
Hi YouRen,
Den tis 9 apr. 2019 kl 22:31 skrev <[email protected]>:
>
> Hello,
>
> Recently, I posted a bug report regarding authentication failures when
> pairing with BLE 4.0 devices. I was told to raise this issued to the
> Bluetooth mailing lists and I hope this is the correct email to contact.
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822633
Could you please also post the HCI log?
In a terminal window, execute "sudo btmon" to start logging. Then try
to pair your device (reproduce the issue). The btmon tool should now
have printed the HCI packets to stdout.
/Emil
Hi You Ren,
Den ons 10 apr. 2019 kl 20:43 skrev <[email protected]>:
>
> Hello Emil,
>
> > Hi YouRen,
> >
> > Den tis 9 apr. 2019 kl 22:31 skrev <[email protected]>:
> > >
> > > Hello,
> > >
> > > Recently, I posted a bug report regarding authentication failures when
> > > pairing with BLE 4.0 devices. I was told to raise this issued to the
> > > Bluetooth mailing lists and I hope this is the correct email to contact.
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822633
> >
> > Could you please also post the HCI log?
> > In a terminal window, execute "sudo btmon" to start logging. Then try to pair
> > your device (reproduce the issue). The btmon tool should now have printed
> > the HCI packets to stdout.
> >
> > /Emil
>
> I have attached a .snoop file from when I attempted to pair the BLE device, would this be acceptable?
I looked at the log in Wireshark. To summarise it, BlueZ sends a
Pairing Request SMP packet (opcode 0x01):
IO Capability: Keyboard, Display (0x04)
OOB Data Flags: OOB Auth. Data Not Present (0x00)
AuthReq: 0x2d, CT2 Flag, Secure Connection Flag, MITM Flag, Bonding
Flags: Bonding
Max Encryption Key Size: 16
Initiator Key Distribution: 0x0d, Link Key, Signature Key (CSRK),
Encryption Key (LTK)
Responder Key Distribution: 0x0f, Link Key, Signature Key (CSRK),
Encryption Key (LTK)
The peripheral device then sends a Pairing Failed SMP packet (opcode
0x05) containing "Invalid Parameters (0x0a)" as result. The link is
then disconnected due to the failure.
It's clear that the pen misbehaves since it sends Invalid Parameters
as response even though BlueZ indeed sends valid parameters.
Anyway, looking at
https://launchstudio.bluetooth.com/ListingDetails/490, it's clear that
the pen PN557W uses a DA14580 chip, which has a Riviera Waves
Bluetooth stack. Unfortunately I know that this stack contains a bug.
Since it was made for a Bluetooth spec earlier than 4.2, there are
five bits in the Key Distribution fields that are reserved for future
use. Per the 4.0 spec, "Reserved is a 5-bit field that shall be set to
zero and ignored on reception." This bluetooth stack does not follow
this but instead sends a Pairing Failed result with Invalid Parameters
as error code when any bit is nonzero. One of those bits got used in
the 4.2 spec and it's called LinkKey which is a bitfield that's set to
1 if the Link Key (used for Bluetooth classic pairing) should be
derived from the BLE key if the two devices some time in the future
would communicate using Bluetooth Classic. Now of course the pen
doesn't support Bluetooth Classic (that can be seen by looking at the
flags in the advertising data). I reported this bug to the company
making DA14580 more than three years ago and they released a patch
short time thereafter which is included in their latest SDKs.
It seems like Dell neither used the latest DA14580 SDK when the
firmware was written (looking at the publish date of 2016-08-31 in the
Bluetooth listings) nor has released a firmware update for it (since I
assume you have installed it if you there was a newer one?).
Could you try remove these two lines at
https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L693
to see if it works (also make sure by looking at the log later that
those bits were not set in the Key Distribution field)?:
local_dist |= SMP_DIST_LINK_KEY;
remote_dist |= SMP_DIST_LINK_KEY;
We have seen the exact same problem when Android 6 was released.
However they have a workaround that they don't set the LinkKey bit if
they suspect the device doesn't support it. I think they look at the
advertising data which indicates in the flags that it doesn't support
BR/EDR. I think BlueZ should do the same to workaround these
incompatibility issues.
/Emil
Hi,
Den ons 17 apr. 2019 kl 20:46 skrev <[email protected]>:
> > Could you try remove these two lines at
> > https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L693
> > to see if it works (also make sure by looking at the log later that those bits
> > were not set in the Key Distribution field)?:
> > local_dist |= SMP_DIST_LINK_KEY;
> > remote_dist |= SMP_DIST_LINK_KEY;
> >
> > We have seen the exact same problem when Android 6 was released.
> > However they have a workaround that they don't set the LinkKey bit if they
> > suspect the device doesn't support it. I think they look at the advertising data
> > which indicates in the flags that it doesn't support BR/EDR. I think BlueZ
> > should do the same to workaround these incompatibility issues.
> >
> > /Emil
>
> Sorry for the late response, the pairing process succeeds when the two
> lines are removed from smp.c. I'm inquiring whether we have a patch
> that already addresses this issue and if not, how it can be implemented.
Good. Tell me if you need help with the patch on the peripheral side.
> Just to make sure I understand this correctly, the PN557W sees the Link
> Bit and returns Invalid Parameters because the bit is nonzero, correct?
> This causes the pairing process to fail. By commenting out those two
> lines, we are telling the master to not set the link bit to 1 before sending
> the parameters?
>
> /Joey
Exactly.
/Emil