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.

[Francis]

Thank you for the reply. I did end up trying something like this and it is working. In my reading of the whitelist and IRK for SoftDevice, it appears that enabling the whitelist is what causes the irk_match in ble_gap_evt_connected_t to be flagged to true. This seems like something the device_manager_peripheral implementation keys off of to properly find the same device, otherwise it defers to the peer address, which would be changing I think over time due to the use of IRK.

Is my understanding correct here? If so, how best can I manage duplicates? I can envision iterating over the recorded device list upon a new recording and clearing any old ones with the same matching IRK, if any.