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]

I'm using a Nexus 6 running v6.0.1. I get a BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE as part of the BLE_GAP_EVT_CONNECTED event.

Thanks for the replies and example. I will adapt them to fit my use case.

It's a bit unfortunate that IRK matching only happens when whitelist is enabled. It may be too big an API change, but couldn't the IRK still be matched when a whitelist is supplied, but the filtering policy is set to BLE_GAP_ADV_FP_ANY? Is there some underlying implementation detail that motivates it being the way it is today?