Re: Unexpected SMP Command 0x0a

Hi Joshua,

I would like to follow up with this issue.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Yes, for secure connection the LTK is generated locally.
But issue here is observed that after Pairing is complete the
key distribution is not completed from Master.

i.e. After Slave sends the  "Signature key:" but Master doesn't
share any key.  Attached logs.

I get that and that is clear from the logs. Something is
stalling here and because of that, you run into the 30 seconds SMP

timeout.

quoted

quoted

quoted

quoted

quoted

We just need to know if the 4.9 kernel is doing this correctly.
If so, then you can bi-sect that patch that fixes. Without proof
that
4.9 is also broken, nobody will even bother to chase this down.

I think the problem here is race between ACL data and HCI events
on USB dongle...  We get initial slave keys but those get dropped
due to encryption changed event not being received yet. Since
keys were silently dropped we later on get unexpected SMP PDU and
ignoring remaining keys as well which eventually leads to SMP

timeout.

quoted

quoted

quoted

quoted

If this is USB dongle (using btusd) then only (AFAIK) solution
would be to have a workaround for this inside chip (it would
delay ACL data received right after encryption change giving host
time to handle encpryption

change event).

quoted

quoted

Bluetooth specification for USB transport is unfortunatelly kinda

broken.

quoted

quoted

quoted

quoted

--
pozdrawiam
Szymon Janc

Thank you for your reply. Your inputs are valuable to us in
helping to debug the

issue. Yes, we are indeed using the btusb kernel module and it is
using a USB interface (Bluetooth over USB).

quoted

I noticed that when btmgmt settings are set to turn 'bredr off',
the 'ssp' mode

also turns off. Is this behavior expected to occur?

quoted

My current settings are 'powered connectable discoverable bondable
le

secure-conn’

the SSP (Secure Simple Pairing) is a BR/EDR only feature. So when
you disable BR/EDR, it will be disabled as well.

Thank you for your reply. It looks like I have understood this
incorrectly as initially I read somewhere that LE adopts the SSP model
in v4.1. Looks like this is not the case.

From the specification, I noted that SSP was introduced in BR/EDR in
v2.1 which makes it a BR/EDR only feature.

I finally understand why ssp mode is disabled when I turned bredr off
via btmgmt. Thank you for your clarification!

I notice a strange behavior during the LE Secure Connection pairing. This occurs at the LE Start Encryption event as seen in the following log:


< HCI Command: LE Start Encryption (0x08|0x0019) plen 28       [hci0]
55.230548
        Handle: 128
        Random number: 0x0000000000000000
        Encrypted diversifier: 0x0000
        Long term key: 0e01142be9ddab9e6e6cef545562adc4

quoted

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

      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)

quoted

ACL Data RX: Handle 128 flags 0x02 dlen 21                   [hci0] 55.500569

      SMP: Signing Information (0x0a) len 16
        Signature key: 1d916d5951791a271416a161cda981d6

quoted

HCI Event: Encryption Change (0x08) plen 4                   [hci0] 55.513836

        Status: Success (0x00)
        Handle: 128
        Encryption: Enabled with AES-CCM (0x01)


As noticed from the logs above, the "SMP: Signing Information (0x0a)" command appears first before the "Encryption Change (0x08)" HCI event. On a LE successful pairing, the encryption change should occur before the signing information command as can be 
observed in the following log below. I was able to successfully perform a LE pairing through forced trial. The successful LE pairing only occurs 1 out of 10 times.

the problem is that we will need to wait for the Encryption Change before we can accept any key distribution from the remote side. So is this on an USB dongle? The over the air packet might be actually encrypted, but on the USB HCI transport we see it as non-encrypted and drop it.

So what hardware is this actually? Do you happen to have newer firmware for this hardware that fixes this race in the HCI lower transport.

Regards

Marcel