peer manager bond control

RE: peer manager bond control

Petter Myhre — Mon, 13 Jun 2016 07:24:42 GMT

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?

RE: peer manager bond control

Jim Dattolo — Tue, 07 Jun 2016 14:47:41 GMT

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.

RE: peer manager bond control

Jim Dattolo — Wed, 01 Jun 2016 12:31:02 GMT

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?

RE: peer manager bond control

Jim Dattolo — Wed, 01 Jun 2016 12:26:32 GMT

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.

RE: peer manager bond control

Petter Myhre — Wed, 01 Jun 2016 11:59:59 GMT

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?