NCS/Zephyr peripheral_sc_only can't reconnect after bonding to nRF Connect Desktop BLE Standalone tool

[variant]

Once you pair an nRF52480 devkit running the sample app peripheral_sc_only with the nRF Connect for Desktop Bluetooth Low Energy Standalone tool, you can't reconnect after the initial disconnect.

If instead of the desktop app I use the Android mobile app nRF Connect tool, I don't have that problem.  That is, I can bond, disconnect, and then successfully reconnect.

Steps:

1. Build peripheral_sc_only as-is for the nRF52840 devkit.

I am using NCS 2.2.0, but I think the problem has existed since at least 1.9.1.

2. Set the desktop BLE tools security parameters as shown below.  I am using nRF Connect for Desktop Bluetooth Low Energy Standalone v4.0.0, but I think the problem has existed with many older versions too.

3. Initiate the BLE connect from the BLE tool.

4. In the BLE tool, enter the passcode printed in the peripheral's terminal window.

5. Pairing succeeds. Log from peripheral is as follows:

Connected F6:71:A1:D7:32:D5 (random)
Passkey for F6:71:A1:D7:32:D5 (random): 787282
Pairing Complete
Security changed: F6:71:A1:D7:32:D5 (random) level 4

6. Initiate disconnect from the BLE tool.

7. Initiate connect from the BLE tool.

8. Connection is attempted but fails.

Log from peripheral is as follows:

Connected F6:71:A1:D7:32:D5 (random)
Security failed: F6:71:A1:D7:32:D5 (random) level 1 err 9
Disconnected from F6:71:A1:D7:32:D5 (random) (reason 0x3d)

Note that disconnect reason 0x3d is BT_HCI_ERR_TERM_DUE_TO_MIC_FAIL.

The BLE tool shows a disconnect timeout reason of BLE_HCI_CONNECTION_TIMEOUT.

9. Wireshark shows the following for this reconnect attempt:

You can see in the Wireshark log that the central (BLE tool) repeatedly sends a packet of length 5 bytes but without any response from the peripheral.

In the sample app, I also enabled printing the sniffer key by setting  CONFIG_BT_LOG_SNIFFER_INFO=y.  However, even Wireshark is not able to decrypt the encrypted data when I provided it with the SC LTK.

I don't know if this is an issue with the BLE tool or the NCS/Zephyr.  Regardless, it seems like a basic use case that should work out of the box.

Could it be that the BLE tool is not encrypting correctly?

[Hieu]

Hi variant,

My apology for the long wait. There was some holiday understaffed situation and private health issues on my part.

I have reproduced your issue, but I am having trouble obtaining a full log of the Bluetooth stack, as the application runs into a memory access fault with full logging enabled.

I attempted to reproduce the issue with the BMS sample. There is also failure making a connection after bonding there. However, the disconnection reason is different.

I will forward these findings to the team behind the BLE Standalone app to see if they have any insight into this problem.

As I am out of office for the rest of the week, I will follow-up on this by the end of Mon Jan 9. If you need this urgently for some reasons, please let me know and I will arrange some alternatives.

Hieu

[variant]

Thanks Hieu.  There is no urgency on my part. 

[variant]

Yes, that's fine to continue using Android nRF Connect, Hieu.  Thanks for the update.

[Hieu]

Hi variant, the team behind the app confirmed the issue. Please be informed.

I cannot comment on when a fix would be available, however.

My apology for the inconveniences, both for the issue and for being unable to give you a bug-fix date.

[variant]

Thanks Hieu.  There's no problem to use a mobile device for now.  I'm happy that the app team is now aware of the issue.  Thanks again.

[eos8233]

Hi Hieu, are there any further updates on this? I believe I am being impacted by the same issue.

In my case, I have two nrf52 devices acting as central and peripheral. Bonding is successful, but if the connection is disconnected they cannot reconnect until the peripheral is rebooted.

Reconnection attempts fail with the same error message on the central (Security failed err 9), while the peripheral produces no log messages indicating a connection attempt.

[Hieu]

Hi eos8233 , 

I don't think your issue is the same, because the root cause of variant's issue is in the nRF Connect for Desktop BLE feature.

By the way, when you reply to old threads, there is a chance that it has already been closed, and Nordic's Application Engineers like me won't get notified of your reply. It happened this time, and I only found your reply while looking up my old cases.

If you run into such situation, please consider opening a new question instead.

Hieu