[nRF52833] Bonding again with already bonded Central fails

[Marco R]

Hi,

I'm working on a legacy program (Peripheral) using nRF52833 and nRF5 SDK using SoftDevice S113.

I'm using the Peer Manager module to manage bonded hosts/data. It seems the Peripheral is failing to bond (the second time, via JustWorks pairing) with an already bonded Central, even though I'm adding the following call in response to Peer Manager event PM_EVT_CONN_SEC_CONFIG_REQ:

        case PM_EVT_CONN_SEC_CONFIG_REQ:
        {
            NRF_LOG_INFO("PM_EVT_CONN_SEC_CONFIG_REQ");
            pm_conn_sec_config_t conn_sec_config = { .allow_repairing = true };
            pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
        }
            break;

Here is the list of BLE/PM events my application is getting, that result in Bonding failing:

<info> app: pm_evt_handler Event: 0x1
<info> app: pm_evt_handler Event: 0x6
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<info> app: pm_evt_handler Event: 0x9
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: pm_evt_handler Event: 0x0
<info> app: PM_EVT_BONDED_PEER_CONNECTED
<info> app: pm_evt_handler Event: 0xF
<info> app: ble_evt_handler Event: 0x10
<info> app: Connected
<info> app: pm_evt_handler Event: 0x2
<info> app: pm_evt_handler Event: 0x6
<info> app: pm_evt_handler Event: 0x5
<info> app: PM_EVT_CONN_SEC_CONFIG_REQ
<info> app: ble_evt_handler Event: 0x13
<info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
<info> app: ble_evt_handler Event: 0x3A
<info> app: ble_evt_handler Event: 0x19
<info> app: BLE_GAP_EVT_AUTH_STATUS
<info> app: Authorization failed with code: 133!

I was expecting that passing 

allow_repairing

bool to true would allow the new bonding attempt to succeed and update the Peer Data information in FDS, but it doesn't seem to be the case.

Can you advise on what should I do differently to allow re-bonding to a Central? Should I handle event BLE_GAP_EVT_SEC_PARAMS_REQUEST? If so, what API and parameters should I call?

Thanks,

Marco

[Sigurd]

Hi,

I would also have assumed that passing allow_repairing=true was enough. I can try to reproduce the behavior here. What SDK version are you using? What kind of device did you use as central?

[Marco R]

Hi Sigurd, thanks for the reply. I'm using nRF5_SDK_17.1.0_ddde560. It reproduces with both iOS (iPhone13) and Android (Pixel 7)

[Vidar Berg]

Hi Marco, we have not been able to reproduce this here, unfortunately. I used the ble_app_hrs example from SDK 17.1.0 and created a new configuration for the nRF52833 DK (pca10100) with s113 and then tested it with an iPhone 12.

Here is the debug log I got when I had the phone bond again with the nRF:

And the project I used:

6305.ble_app_hrs.zip

Maybe you can try to place a breakpoint at the two lines I have highlighted below to confirm where the security status ends up being set to BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP (133).

Best regards,

Vidar

[Marco R]

Hi Vidar, thank you very much for providing the example and especially for pointing me to the security_dispatcher.c relevant code.

I found the bug in my code. My call to pm_conn_sec_config_reply() was getting ignored by the security_dispatcher due to user_flag_is_acquired(m_flag_allow_repairing) failing. 

The reason it was failing is because when I copy-pasted code between two example apps, I inherited the call to ble_conn_state_init() (which some examples call in services_init() ) which internally memsets to zero the global user flags m_bcs.acquired_flags -- which are checked by user_flag_is_acquired(m_flag_allow_repairing).

Removing that call fixed my issue.

Thanks for the help!

[Vidar Berg]

Hi Marco, Good catch! I am happy to hear you found the problem. 

Calling ble_conn_state_init() after Peer manager init can lead to various hard to debug issues as it will clear the flags set by the peer manager during initialization. I have suggested to the SDK team that we have to find a way to make this clearer to users. For instance, by adding a note in the API documentation.