Re-pairing NRF BLE with the same host without manual bond erase button pushing

[Olli]

Hello.

I am developing a BLE application on NRF52832 using Nordic SDK11 and S132 softdevice. I use Linux PC as a BLE host device, and can pair & bond the NRF bluetooth device with the Linux host. I use encrypted connection settings BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM and just-works pairing mode. I use peermanager library for storing the bonding information in the NRF BLE device.

My question relates to an IoT'ish situation that the NRF BLE device and the host (Linux) devices are happily paired&bonded together and reside somewhere in the field, so that I can remotely communicate with the host device over the Internet, yet there won't be anyone physically present in the field to perform manual interactions. Now let's assume an adverse situation that the (Linux) host would lose it's bluetooth pairing information for whatever reason.

Question: How can I make the NRF device accept renewed pairing request from the host device that has earlier been paired with this same NRF BLE device, yet the (Linux) host device does not have earlier pairing information available any more?

The issue is that the NRF BLE device rejects pairing requests with the host device, if the NRF BLE device recognizes the host device by its MAC as one with earlier bonding information recorded into the NRF's flash storage.

I can manually re-establish pairing between the NRF BLE and host devices by pushing physical button on NRF BLE device to force NRF's peermanager to forget the earlier bonding, but how I could achieve this in software so that there won't be need for anyone be physically present in place to push the erase-bonding-button on the NRF BLE device?

[FormerMember]

The peer_manager code is set up so that it will reject a new bonding procedure from devices with already stored bonding information.

Starting from the first received event in the pairing process, BLE_GAP_EVT_SEC_PARAMS_REQUEST, the piece of code that rejects the new bonding process can be found the following way:

BLE_GAP_EVT_SEC_PARAMS_REQUEST --> security_dispatcher.c:

smd_ble_evt_handler( --> BLE_GAP_EVT_SEC_PARAMS_REQUEST --> sec_params_request_process)

-->

sec_params_request_process(--> SMD_EVT_PARAMS_REQ)

-->

smd_evt_handler( --> SMD_EVT_PARAMS_REQ --> smd_params_reply_perform(..))

In smd_params_reply_perform(..) there is a check if the connected device already is bonded. And if it is already bonded, the pairing procedure will be rejected:

static void smd_params_reply_perform(uint16_t conn_handle)
{
ret_code_t err_code;

if (  (ble_conn_state_role(conn_handle) == BLE_GAP_ROLE_PERIPH)
    && im_peer_id_get_by_conn_handle(conn_handle) != PM_PEER_ID_INVALID)
{
    // Bond already exists. Reject the pairing request if the user doesn't intervene.
    ble_conn_state_user_flag_set(conn_handle, m_sm.flag_id_reject_pairing, true);
    send_config_req(conn_handle);
}
else
{
    ble_conn_state_user_flag_set(conn_handle, m_sm.flag_id_reject_pairing, false);
}
....

[Olli]

Great, this worked!

I inserted there a small safety condition that if at least NN hours have elapsed since previous communication, then the NRF device agrees to pair again with the same host, to allow re-pairing yet avoid possibility that other malicious host mimicking the same Mac would attempt to steal the bonded connection from the actual authorized host.

Many thanks also for the quick reply: Support in this forum is awesome, I've discovered answers to dozens of my earlier questions by searching Q&As in this forum!