Loss of bonding key

RE: Loss of bonding key

Kenneth — Fri, 12 Jul 2019 10:59:52 GMT

I see your point, this shouldn't occur no. There should at least be some check that if it's only one bond (e.g. call pm_peer_count()), then the pm_peer_delete() is not executed. Considering you only have one bond you may just set flash_write_after_gc to true always. You are free to change this as you see fit.

An alternative may be that you on each disconnection call fds_stat(), and then run fds_gc() before PM_EVT_STORAGE_FULL may occur.

RE: Loss of bonding key

jhewitt — Thu, 11 Jul 2019 18:31:16 GMT

You say in your response that there is no automatic deletion of the peer based on it's rank. When this event occurs it is because peer_manager_handler.c line 350 is executed in the function pm_handler_flash_clean() with state PM_EVT_STORAGE_FULL. How do I configure the app to allow this state to occur without the call to pm_peer_delete() on line 350? This line deletes the lowest ranked peer even when it is the only peer.

RE: Loss of bonding key

Kenneth — Thu, 11 Jul 2019 17:08:47 GMT

You may disable the rank system, especially if you only have 1 bond at any time. The intention of the rank system is for the application to be able to have some kind of knowledge of which peer have been used last or least. The rank will be updated each time you connect to a peer, and that is really it. There is no automatic deletion of the peer based on it's rank, this must be handled by the application in some way based on application criteria (e.g. need to delete a bond to make room for a new). I am not sure what a good idea it is to frequently update CCCD's, since they will trigger flash write (and possible erase) operation frequently. A better idea would be to simply have CCCD's enabled all the time, but instead the peer can write a command on demand that the application will use to decide if it should send notifications or not.

RE: Loss of bonding key

jhewitt — Thu, 11 Jul 2019 10:09:55 GMT

Nordic engineer to be assigned ... applying both of the above changes did correct the encryption failure issue that was being created. The change to allow re-pairing is a security risk and therefore not considered an acceptable solution. Is this condition being created because of the PM_PEER_RANKS_ENABLED option and, where is there documentation that describes the behavior of this option? I would expect this option to delete the lowest ranked peer only when the number of bonded peers approaches the value assigned to PM_RA_PROTECTION_TRACKED_PEERS_NUM which is eight in my case. Does this option also delete the only peer that is bonded when peer manager executes garbage collection anyway?

While awaiting my answers I will back out the change to allow re-pairing and see if the condition returns after another 18 hour test.