peer manager bond control

[Jim Dattolo]

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?

[Petter Myhre]

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?

[Jim Dattolo]

I am deleting the old peer when the CONN_SEC_SUCCEEDED event is thrown so that works. So if I call pm_sec_params_set with bond=0 after I get my first one I can set it back to 1 when the user wants to replace the existing bond? That kind of makes sense. I was trying to work within the events but this is a lot simpler. Thanks, I'll try it and let you know later today if it works. If it does that makes things really simple on my peripheral role side.

[Jim Dattolo]

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?

[Jim Dattolo]

so right now I am just letting it limit cycle and alerting the user on the side with the UI that the bond is failing. This triggers the user to go "aha" and then interact with the peripheral side to enable pairing. When the cycle comes around it starts the pairing off. The central side always erases bonds when starting a new pairing cycle.

[Petter Myhre]

I don't see how including a bit in advertisment would avoid a connect->pairing failed. The peripheral wouldn't know that the central has deleted its bond. You would only be able to set the bit after a connect->pairing failed wouldn't you?