Wrong disconnected reason due to encryption with incorrect LTK

[Remo]

Hi

I'm using the nRF52832 with the SoftDevice S132 V6.0.0 in the central role and would like to encrypt a link with a stored LTK.

The encryption with the function sd_ble_gap_encrypt() with the correct LTK works fine. But when I start the encryption procedure with a peripheral that has an incorrect LTK, I would have expected that the BLE_GAP_EVT_DISCONNECTED event with the reason 0x3D (MIC failure) occurs, as it is described in this MSC.

Instead, I get the BLE_GAP_EVT_DISCONNECTED event with the reason 0x08 (Connection Timeout) after the supervision timeout expired. Am I doing something wrong or is this a bug in the SoftDevice?

EDIT:

I have a further question. Is that correct that the parameters lesc, auth and ltk_len in the ble_gap_enc_info_t struct are not needed/respected by the function sd_ble_gap_encrypt?

Many thanks in advance for your help.

Best regards

[Kenneth]

Hi,

What is the disconnect reason on the peripheral? Is there any assert on the peripheral? Do you have an on-air sniffer log?

In general I recommend to update to S132v6.1 due to various bug fixes and improvements.

Best regards,
Kenneth

[Remo]

Hi Kenneth

Unfortunately, I don't know the disconnect reason of the peripheral, because this device is not under my control. Here is a snippet from the sniffer:

I assume that the packet with the error is the LL_START_ENC_RSP from the peripheral that couldn't be decrypted.

I tried it also with the S132 V6.1 but the effect was the same.

Best regards

[Kenneth]

We believe that what is happening is the following:

The peripheral will fail the MIC check and disconnect with error code MIC failure, it will not send any information to the central, so the central will reach supervision timeout and disconnect with error code timeout.

[Remo]

But on the sniffer, I see a frame sent by the peripheral after the LL_START_ENC_RSP sent by the central. Isn't that the encrypted LL_START_ENC_RSP from the peripheral?

I've now also used an nRF52-DK with S132 V6.1.0 as peripheral device to verify the behavior. The disconnect reason on the peripheral is 0x3D (MIC failure) as expected. But the disconnect reason on the central is still 0x08.

[Remo]

Do you have any news?

[Kenneth]

Not really, we do believe the root cause is as I wrote earlier. 

Best regards,
Kenneth

[Remo]

How does the S132 V6.1.0 in the peripheral role behave in case of a MIC failure? Does it also not send an answer to the central? Because in this case the central device also reached the supervision timeout.