This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

peer manager bond control

what I am basically trying to do is only allow a single bond and any new bonds disallowed until the user selects and option to allow a new bond and then and only then delete the old one. I can't delete the old bond until the new one succeeds.

I would assume that I can respond to the BLE_GAP_EVT_SEC_PARAMS_REQUEST event, however the PM code is doing that. Can I route the event to me instead of PM or do I still need to send it over for accounting purposes?

I also want to disallow all non LESC/MITM/BOND requests so it sounds like I need to do it here unless there is some config option to do.

This is for both the central and the peripheral. Each is normally bonded to one another until the user wants to move the peripheral to another central that may or may not have a previous bond. The central should have it happen automatically and the peripheral needs a long button press to start the process. I can't simply delete all bonds on the device since I need to recover if the new pairing attempt is aborted or not finished (e.g. user accidentally presses the button to start the process) I can't do the button press while power is cycled since power is always applied and the device is doing something that cannot be interrupted which is why I want to do this bond change over with only ever one in the fstorage (the one that is successfully connected with a bond)

any ideas?

Parents
  • I have a suggestion.

    pm_sec_params_set() can be called multiple times. You can disallow new bonds by calling it with NULL. If a bonded device connects, it will still be able to re-encrypt the link.

    You can delete a bond with pm_peer_delete(), maybe you can do this when you get the PM_EVT_CONN_SEC_SUCCEEDED event for the newly bonded peer?

  • one last thing. When I delete the old bond on the central but not on the peripheral and the central connects to the peripheral and it tries and secure the link both sides throw a 0x85 in p_ble_evt->evt.gap_evt.params.auth_status.auth_status. I'm trying to work out what to do when this happens, I don't want to simply repair on the peripheral since it could be an attacker. Right now I am leaning towards using a bit in the mfg spec data in the adv packet to state that this peripheral radio needs to be repaired and to alert the user on the central's UI. That way I don't limit cycle through connect/fail/reconnect. Is there an easier way for this case?

Reply
  • one last thing. When I delete the old bond on the central but not on the peripheral and the central connects to the peripheral and it tries and secure the link both sides throw a 0x85 in p_ble_evt->evt.gap_evt.params.auth_status.auth_status. I'm trying to work out what to do when this happens, I don't want to simply repair on the peripheral since it could be an attacker. Right now I am leaning towards using a bit in the mfg spec data in the adv packet to state that this peripheral radio needs to be repaired and to alert the user on the central's UI. That way I don't limit cycle through connect/fail/reconnect. Is there an easier way for this case?

Children
No Data
Related