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]

Do you have a sniffer trace ? Are you sure the slave didn't crash ? Have you tried to debug ?

[Pitius Tec S.L.]

Yes, I have sniffer traces, added now to the question. The slave don´t crash. I covered out that the problem is in the Initiator key. On Android the request gives 3 posiibilities, LTK, IRK and CSRK. The slave answers with IRK.

On Windows the request is only LTK as Initiatorkey. The slave answers without specifying the Initiator key (empty value). Then Windows sends severall requests, but the slave dont answer anymore...

[Hung Bui]

I don't think the Initiator key here is the issue. On the Sniff.pcapng on Windows, the PC uses public address, it doesn't need to exchange the IRK (which supports Random Resolvable address). IRK is not needed. The reason the master threw Pairing Failed Reason: Authentication Requirements (0x03) , in my opinion, was that the nRF5 send pairing response with MITM not supported and no IO capability. The windows PC rejects because the requirement for this particular application need MITM.

The sniffer trace doesn't match with what you described earlier, the master try to bond first with MITM and then reject bonding and bond again.

In the sniffer what I can see is it tried to bond, and reject bonding but after that the peripheral crashed. Most likely because the pairing rejection is not handled in your nRF5 code. Could you try to debug and figure out why it crashes ?

[Pitius Tec S.L.]

I told, the peripheral dont crashes. A breakpoint in the Error_Handler and a breakpoint at Reset are not reached. The peripheral disconnects. If I activate MITM happens the same. No difference. Here some Sniffer-Outputs:

85 28.296873000 Master Slave SMP 37 Rcvd Pairing Request: Bonding, MITM, Initiator Key(s): LTK , Responder Key(s): LTK

88 28.310734000 Slave Master SMP 37 Rcvd Pairing Response: Bonding, MITM, Initiator Key(s): , Responder Key(s): LTK

89 28.322010000 Master Slave SMP 32 Rcvd Pairing Failed: Authentication Requirements

[Hung Bui]

Do you have any IO capability ? With no IO capability how could you do MITM ? If it doesn't crash (which very unlikely) you should have BLE_GAP_EVT_DISCONNECTED event returns, could you check that event ?
But I never seen any trace that the slave suddenly stopped responding like that without a crash.