Re: 5.41 - Authentication Failed with kernel 4.2.0

Hi Johannes,

quoted

quoted

quoted

quoted

we had a problem when attempting to pair low energy devices on
Ubuntu

with kernel version 4.2.0-42-generic:

quoted

After scanning there always occured an "authentication failed" error.
The devices we tried to pair were a A&D UC-352-BLE weighing scale
and a

A&D UA-651BLE blood pressure monitor.

quoted

Both devices can be paired on the same machine with the same setup
but

with kernel version 3.13.0.92.

quoted

Unfortunately the log doesn't give me an idea what the problem is.

Here is the output using bluetoothctl:
[bluetooth]# pair 5C:31:3E:5E:54:5E Attempting to pair with
5C:31:3E:5E:54:5E [CHG] Device 5C:31:3E:5E:54:5E Connected: yes
Failed to pair:
org.bluez.Error.AuthenticationFailed
[CHG] Device 5C:31:3E:5E:54:5E Connected: no

Did you also have an agent registered? (e.g. "agent KeyboardDisplay"
in
bluetoothctl)

Yes, an agent was registered in bluetoothctl with "agent on"

Ok, good. It shouldn't make a difference for pairings initiated from the local
side, but just in case, did you also issue "default-agent"?

quoted

quoted

What would give an even better view of what's going on is the HCI logs.
You can get those with the btmon tool (found under monitor/ in the
BlueZ source tree).

Here is the output of btmon. Does it mean anything to you?
....
< ACL Data TX: Handle 70 flags 0x00 dlen 11                    [hci0] 28.489379
     ATT: Read By Group Type Request (0x10) len 6
       Handle range: 0x0018-0xffff
       Attribute group type: Primary Service (0x2800)

quoted

HCI Event: Number of Completed Packets (0x13) plen 5         [hci0]

28.559451

quoted

       Num handles: 1
       Handle: 70
       Count: 1

quoted

HCI Event: Number of Completed Packets (0x13) plen 5         [hci0]

28.560451

quoted

       Num handles: 1
       Handle: 70
       Count: 1

quoted

ACL Data RX: Handle 70 flags 0x02 dlen 6                     [hci0] 28.628456

     SMP: Pairing Failed (0x05) len 1
       Reason: Confirm value failed (0x04)
< HCI Command: Disconnect (0x01|0x0006) plen 3                 [hci0] 28.628506
       Handle: 70
       Reason: Authentication Failure (0x05)

To me this looks like the remote either rejected the pairing, or something else
went wrong there. It'd help to see the full HCI log, particularly from the
beginning of the SMP session, i.e. including the Pairing Request and Response
PDUs.

Johan

Here is the whole log:

quoted

HCI Event: Command Status (0x0f) plen 4                      [hci0] 28.080411

     LE Create Connection (0x08|0x000d) ncmd 1
       Status: Success (0x00)

quoted

HCI Event: LE Meta Event (0x3e) plen 19                      [hci0] 28.086410

     LE Connection Complete (0x01)
       Status: Success (0x00)
       Handle: 70
       Role: Master (0x00)
       Peer address type: Public (0x00)
       Peer address: 5C:31:3E:5E:54:5E (OUI 5C-31-3E)
       Connection interval: 70.00 msec (0x0038)
       Connection latency: 0.00 msec (0x0000)
       Supervision timeout: 420 msec (0x002a)
       Master clock accuracy: 0x00
< HCI Command: LE Read Remote Used Fea.. (0x08|0x0016) plen 2  [hci0] 28.086498
       Handle: 70
@ Device Connected: 5C:31:3E:5E:54:5E (1) flags 0x0000
       02 01 05 03 02 1d 18 05 12 40 00 50 00           .........@.P.   

quoted

HCI Event: Command Status (0x0f) plen 4                      [hci0] 28.090427

     LE Read Remote Used Features (0x08|0x0016) ncmd 1
       Status: Success (0x00)

quoted

ACL Data RX: Handle 70 flags 0x02 dlen 6                     [hci0] 28.145172

     SMP: Security Request (0x0b) len 1
       Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)

this is an odd event. So we are initiation the pairing, but the remote side is sending Security Request for no apparent reason. This means I am suspecting that we are just dropping this PDU and not acting on it.

This could be tested by adding a debug print in smp_sig_channel() for this statement

        if (smp && !test_and_clear_bit(code, &smp->allow_cmd))                   
                goto drop;

What we might need to do is allow SMP_CMD_SECURITY_REQ and then let it set SMP_FLAG_LEGACY_SLAVE in case SC is not set.

quoted

HCI Event: LE Meta Event (0x3e) plen 12                      [hci0] 28.209459

     LE Read Remote Used Features (0x04)
       Status: Success (0x00)
       Handle: 70
       Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
         LE Encryption
< ACL Data TX: Handle 70 flags 0x00 dlen 11                    [hci0] 28.209526
     SMP: Pairing Request (0x01) len 6
       IO capability: NoInputNoOutput (0x03)
       OOB data: Authentication data not present (0x00)
       Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
       Max encryption key size: 16
       Initiator key distribution: EncKey Sign LinkKey (0x0d)
       Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)

If my suspicion is correct and we ignore Security Request above, that this Pairing Request is not a section based on Security Request. It is genuine new attempt to pair the device.

I would not be surprised if the auth requirement RFU bits or key distribution RFU bits are getting cleared by the peripheral and the raw PDU is used wrongly in confirm value calculation.

However that is easy to test and see if paring succeeds when manually doing "btmgmt sc off". Then the SC bit and LinkKey bits should not be set in the Pairing Request. If that succeeds then this is a broken peripheral.

Regards

Marcel