nRF51x, S110, pairing request with Initiator key LTK

[Pitius Tec S.L.]

Thats the problem. On Windows7, 64 bit, with the Bluetooth Stack from the USB BLE-Stick happens the following: Windows (master) initiates the connection, sends a security requierement of Bond=1, MITM=1, etc... I do´nt support MITM, so it fails with error 0x83, but the Master sends after this a second pairing request with Bond=1, MITM=0 etc..., so it decreased the security levels, starting with the highest.

But the slave does not answer anymore.

The problem is in S110 V6.0.0 til S110 V8.0.0 the same.

How can I change, that the slave dont disconnect in the given timeout? I will, that he should response all request, so that the master can determine the higest available security level.

Update.

After a lot of sniffing and playing with Android and Windows I´ve note, that the main problem is not the MITM or Bonding, is the requested Initiator Key Type.

On Android: Sniff_android.pcapng 677 6.821182000 Master Slave SMP 37 Rcvd Pairing Request: Bonding, MITM, Initiator Key(s): LTK IRK CSRK , Responder Key(s): LTK IRK CSRK
680 6.872967000 Slave Master SMP 37 Rcvd Pairing Response: Bonding, No MITM, Initiator Key(s): IRK , Responder Key(s): LTK IRK

Thats fine. The slave answers with IRK.

On Windows: Sniff.pcapng 119 48.358824000 Master Slave SMP 37 Rcvd Pairing Request: Bonding, MITM, Initiator Key(s): LTK , Responder Key(s): LTK 122 48.377210000 Slave Master SMP 37 Rcvd Pairing Response: Bonding, No MITM, Initiator Key(s): , Responder Key(s): LTK

That goes wrong. The Slave answers with an empty Initiator Key. After this, the Master answers with : 123 48.384597000 Master Slave SMP 32 Rcvd Pairing Failed: Authentication Requirements The Slave sends one empty data block.

Then the Master repeats till timeout: 125 48.394607000 Master Slave SMP 37 Rcvd Pairing Request: Bonding, No MITM, Initiator Key(s): LTK , Responder Key(s): LTK

But no more response from the slave....

Here the disconnect event. discon_event.png

[Hung Bui]

There is no point of distributing LTK from both side. LTK is the key to encrypt the link when re-bonding. There should be only one key to be distributed.

We can't assure all the third party products would be compatible with our stack, especially when they acting weird. For example in the trace you provided. Pairing failed because of "Unspecified Reason".

We try our best to make our stack compliance with the spec and compatible with other vendors. But we can't guarantee that it would work with all devices as we don't have control over how they behave.