Hi You Ren, Den ons 10 apr. 2019 kl 20:43 skrev <YouRen.Chen@xxxxxxxxxxxx>: > > Hello Emil, > > > Hi YouRen, > > > > Den tis 9 apr. 2019 kl 22:31 skrev <YouRen.Chen@xxxxxxxxxxxx>: > > > > > > 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
