Hi,
I would like to follow up with this issue.
> > > >>>> 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.
> > > >>> 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.
> > > >>
> > > >> 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).
> > > >> Bluetooth specification for USB transport is unfortunatelly kinda
> broken.
> > > >>
> > > >> --
> > > >> 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).
> > > >
> > > > I noticed that when btmgmt settings are set to turn 'bredr off',
> > > > the 'ssp' mode
> > > also turns off. Is this behavior expected to occur?
> > > > 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
> HCI Event: Command Status (0x0f) plen 4 [hci0] 55.234468
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 55.500569
SMP: Signing Information (0x0a) len 16
Signature key: 1d916d5951791a271416a161cda981d6
> 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.
> HCI Event: Command Status (0x0f) plen 4 [hci0] 171.314097
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 128 flags 0x02 dlen 5 [hci0] 171.378971
ATT: Write Response (0x13) len 0
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 171.379512
ATT: Read Request (0x0a) len 2
Handle: 0x0003
> ACL Data RX: Handle 128 flags 0x02 dlen 9 [hci0] 171.580179
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
< ACL Data TX: Handle 128 flags 0x00 dlen 5 [hci0] 171.580627
ATT: Write Response (0x13) len 0
> HCI Event: Encryption Change (0x08) plen 4 [hci0] 171.580662
Status: Success (0x00)
Handle: 128
Encryption: Enabled with AES-CCM (0x01)
> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 171.581274
SMP: Signing Information (0x0a) len 16
Signature key: bb930ddd0fb84ac71c91f4a33857e7ff
As can be observed in the log above, the encryption change event occurs before the signing information command. This would then lead to a successful LE pairing.
During the times when LE pairing is failing, the log shows that signing information command always appear before encryption change which is not what we would expect it to.
Could this issue be resurfaced as shown in the following patch?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/net/bluetooth?h=linux-4.1.y&id=e3098be40bbde0fdd5fcfa6bf28491db421d333a (Delay LTK encryption to let remote receive all keys)
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=5ed884d765a240593c721711eb9e6d24ceba5e8b (Increase SMP re-encryption delay to 500ms)
I would like some inputs or advice on this scenario.
Thank you.
Best regards,
Joshua
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
