Pairing issue | 0x3D MIC failure error

[SK]

Hello everyone, 

I am using nrf52832 module with SDK v14.2 and SD v5.0.0 for my development.

Recently, i started facing the below issue: 

Once i try to pair the module with the smartphone ( in this case, samsung), its paired fine. Problem happens once i disconnect and try to connect again. Once i try to connect back, it gets disconnected throwing  error --> BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE.

I understand that somewhere message was not decrypted correctly but my question is, why now? It has not happened before in the few months we have been developing. Suddenly this issue came up. 

I tried erasing the module and loading the SD and app again but it still has the same issue. With my older version of the FW, it is throwing issues now.

Attached is the nRF sniffer log from Wireshark that i captured 

Could you guys tell me what can be the cause here? Why will it happen all of a sudden? What can be done to ensure this never happens? 

Thank you! 

Best Regards,

SK

[Sigurd]

Hi,

BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE could indicate that you are using incorrect encryption keys when you try to encrypt the link with a bonded device. Maybe the bonds were accidentally deleted on the phone. Try to remove the bond on both the phone and the nRF, and bond again. 

[SK]

UPDATE: I tried deleting the bonds with this function--> pm_peers_delete(), but problem still persists. 

[SK]

1. I deleted the bond on the phone as well. 

2. Samsung galaxy s9+ 

3. I did turn off and on again to test but problem persisted. 

I have not tried using a different soft device yet, though :/

[Sigurd]

Are you seeing this issue on other phones also, or only the S9+ ?

What security parameters are you using for the Peer Manager ? (See this link)

[SK]

Recently it started with S9+ actually. It was not happening before (4-5 months into development). 

We are using a test phone provided by TP-Link (neffos C9A) which has given consistently same issue.

Security parameters used are as follows:

    // Security parameters to be used for all security procedures.
    stSecParam.bond           = SEC_PARAM_BOND; //1
    stSecParam.mitm           = SEC_PARAM_MITM; //1
    stSecParam.lesc           = SEC_PARAM_LESC;  //0
    stSecParam.keypress       = SEC_PARAM_KEYPRESS; //0
    stSecParam.io_caps        = SEC_PARAM_IO_CAPABILITIES; //BLE_GAP_IO_CAPS_DISPLAY_ONLY
    stSecParam.oob            = SEC_PARAM_OOB; //0
    stSecParam.min_key_size   = SEC_PARAM_MIN_KEY_SIZE; //7
    stSecParam.max_key_size   = SEC_PARAM_MAX_KEY_SIZE; //16
    stSecParam.kdist_own.enc  = 1;
    stSecParam.kdist_own.id   = 1;
    stSecParam.kdist_peer.enc = 1;
    stSecParam.kdist_peer.id  = 1;

Would you say that i am using correct params here? I will check out the link also that you gave. thanks! 

[SK]

Also, i am using a static passkey feature for which BLE_GAP_IO_CAPS_DISPLAY_ONLY has been used. 

[Sigurd]

SK said:

Would you say that i am using correct params here?

Yes, they seem to be fine. Could you check if you are able to reproduce the beahaior with the phone, using the ble_app_gls example in the SDK ? (set SEC_PARAM_LESC to 0).

[SK]

Hi, 

Sorry i was not able to check on it before. Will do so and update you soonest. 

[SK]

Hi,

I found the below link and it seemed to solve the issue. 

https://devzone.nordicsemi.com/f/nordic-q-a/40412/android-phone-loses-bonding-information-when-trying-to-read-characteristic

Changing the delay timer to 900 ms from 400 ms.

I wonder why though? Would you know anything in this regard? Also, i migrated my SDK from 14.2 to 15.3. Thought that might resolve the issue. But it was the security delay timer.  

[Sigurd]

SK said:

I found the below link and it seemed to solve the issue. 

 Great!

SK said:

I wonder why though? Would you know anything in this regard?

Likely an issue with the phone, happening internally in the Bluetooth stack on the phone. A sniffer trace comparing 900ms vs 400ms delay timer might give us some clues, but since this is happening internally on the phone, it’s difficult to say exactly why it’s not able to handle the request at 400ms.