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.

[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.

[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?

[Petter Myhre]

Then it makes sense. Thank you for the information.

The IRK matching comes from filtering done in hardware, and I'm not sure if you could use the hardware only to do matching, not filtering, but I will forward your feedback to the developers.

Another option could be to resolve the addresses in the application, and do the "matching" there. See this and this for more information.