Comment 0 for bug 1822633

When attempting to pair a BLE 4.0 pen using Bluez, we receive authentication errors.

Here is the FW from Jason.

Details:

=======================

I added a few debug statements (patch attached) to the kernel's net/bluetooth/smp.c:smp_sig_channel() function (https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L2883). When I try to pair the PN579X, I get the following logs:

[ 5653.563048] DBG: Received code 2 (allowed = 00000024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 00000028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 00000030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 00000060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 000000a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 00000120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 00000220) with 7 bytes
[ 5654.246182] DBG: Processing code...
[ 5657.610656] input: Dell Active Pen PN579X Keyboard as /devices/virtual/misc/uhid/0005:413C:81D5.0004/input/input23
[ 5657.610997] hid-generic 0005:413C:81D5.0004: input,hidraw0: BLUETOOTH HID vf.08 Keyboard [Dell Active Pen PN579X] on 18:56:80:18:6A:E5

When I try to pair the PN557W, however, I only get the following:

[ 64.924901] DBG: Received code 11 (allowed = 00000024) with 1 bytes
[ 64.924906] DBG: AuthReq = 00
[ 64.924907] ERR: Code not allowed on existing connection
[ 64.924943] Bluetooth: hci0: unexpected SMP command 0x0b from bc:82:5d:fa:5e:b7
[ 64.940314] NET: Registered protocol family 38
[ 65.022326] DBG: Received code 5 (allowed = 00000024) with 1 bytes
[ 65.022331] DBG: Processing code...

The "allowed" value is a bitmap, so 00000024 means that only event code 2 and 5 are allowed. The "smp_sig_channel()" function does allow code 11 ("SMP_CMD_SECURITY_REQ") to be sent from the device at the beginning of the connection but *only* if the "smp" variable hasn't been set yet. It looks like the host starts the pairing process and initializes the "smp" variable, which then prevents code 11 from being allowed.

I did try to force the code to allow code 11 at any time, but this didn't seem to help the situation any. The device still sent code 5 ("SMP_CMD_PAIRING_FAIL") immediately afterwards, just like it does in the trace above. Worse, the kernel logs a general protection fault several seconds afterwards, so it clearly doesn't like the workaround.

I also find it odd that the "AuthReq = 00". I found a copy of the core Bluetooth spec at https://www.bluetooth.com/specifications/bluetooth-core-specification and Vol. 3 Part H Chapter 3.6.7 describes the AuthReq flags. All zero would seem to indicate that no security is requested, and I'm not sure if the kernel enforces a minimum security level or something.

Finally, I also tried the suggestion at https://www.raymondjdouglas.com/blog/2019/airpods-on-arch/ on the assumption that maybe this is an issue caused by LE communication rather than classic BR/EDR communication. Alas, my computer wasn't even able to start the pairing process after making the change.