How to handle DM_EVT_SECURITY_SETUP_REFRESH

[Francis]

Hello,

I am trying to understand how to appropriately handle the Device Manager event of DM_EVT_SECURITY_SETUP_REFRESH as a peripheral.

This occurs when the user loses the bond on the Central side, e.g., the user does a "Forget" device on an Android phone's OS Bluetooth settings menu. This results in a BLE_GAP_EVT_SEC_PARAMS_REQUEST that results in the Device Manager generating the above event.

My goal is to have the Peripheral device gracefully renegotiate the bond either within the connection or in a follow up connection. I'd prefer this to occur without any user interactions or impact to other bonds associated in the Device Manager.

Is there an example I could look at that has this type of user flow?

It's also worth mentioning that I get this behavior only if I have whitelisting enabled using the results created by the dm_whitelist_create() method. If I have whitelist disabled, I do not hit this DM_EVT_SECURITY_SETUP_REFRESH condition at all, but instead, run up against a max bonds limit if I repeatedly "Forget" the bond on the Android phone and re-bond.

Thank you, Francis

[Petter Myhre]

I just tested this with my Samsung Galaxy Note 4 with SDK 11, but I get the DM_EVT_SECURITY_SETUP_REFRESH event independently of if whitelist is enabled or not. I tested with the ble_app_hids_keyboard example.

What about adding a case to device_manager_evt_handler()? Something like:

    case DM_EVT_SECURITY_SETUP_REFRESH:
        err_code = dm_device_delete(p_handle);
        APP_ERROR_CHECK(err_code);
        break;

Then you should be able to bond on the next connection/next time you receive BLE_GAP_EVT_SEC_PARAMS_REQUEST.

[Petter Myhre]

I see. I didn't get any irk_match. My Android device is using the random static address type, so it doesn't need to be resolved, so it doesn't get an irk_match. Is you Android device using the private resolvable address type? What type do you get in p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr_type when you get the BLE_GAP_EVT_CONNECTED event?

Your understanding is correct. If the Android (or iOS) device is using private resolvable address you need to use whitelist to resolve the address, or the nRF5 peripheral will see it as a new device and create a new bond.

If you don't want to use whitelist, you may be able to handle duplicates that way. The problem is that the IRK is only guaranteed to be the same when the bond is valid, if the bond on the phone is deleted, then the IRK could change.

An alternative could be to delete the least recently stored bond, see this.