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

Delete all but recent peers when PM_EVT_STORAGE_FULL event happens

Hi,

I'm using nRF52832 with IAR and SDK V15, S132.

I incorporated the peer manager in the uart serial profile example.

I assume, since I have 3 pages (inc. GC) set in FDS, that the Device and Central can store about 50 bonded peers.

As far as I understand, once a new bond request is received and there's no more space left I will get the PM_EVT_STORAGE_FULL event.

Currently, in that event the following code is implemented:

          err_code = fds_gc();

          if (err_code == FDS_ERR_NO_SPACE_IN_QUEUES)
          {
            err_code = fds_gc();
            APP_ERROR_CHECK(err_code);
          }
          else
            APP_ERROR_CHECK(err_code);

This makes no sense as the FDS is used only for bonded device information, so I assume I must delete the peers before running the fds_gc() function.

I read that the peers cannot be deleted when the device is connectable or connected, so is it safe to delete the peers in this event?

Also, is it safe to delete the peers in the PM_EVT_CONN_SEC_FAILED event?

Please answer the above regarding both Central and Peripheral.

The function pm_peers_delete() deletes all peers, how can I modify it to delete only the oldest peers? say, half of the stored peers?

Thank you

Parents
  • so I assume I must delete the peers before running the fds_gc() function

    Your assumtion is wrong. Please re-read the chapter on how fds works: It keeps stale data next to "current" data records. This could exaust your flash pages, even when most of the space in each page is "stale".

    The fds_gc() function copies the "current" records into new page(s) - thus compacting the data.

    Also, is it safe to delete the peers in the PM_EVT_CONN_SEC_FAILED event?

    Probably not, because an attacker can now force you to delete your bonding. But we know nothing about your application...

    The peer manager has a ranking function that one could use in order to determine the newst/oldest peer for deletion.

  • Your assumtion is wrong. Please re-read the chapter on how fds works: It keeps stale data next to "current" data records. This could exaust your flash pages, even when most of the space in each page is "stale".

    According to here:

    "FDS relies on garbage collection to reclaim flash space used by records that have been invalidated....... if there are any dirty records in flash which can be garbage collected."

    As far as I understand previously bonded devices information is not invalidated and not "dirty" so why will the garbage collector reclaim this space?

    And as response to question #2 here:

    "You can check whether there are deleted records in flash, using fds_stat() for instance. If fds_gc() does not free enough space, then the record cannot fit in flash: the flash is full. You have to delete something and run GC."

    So, please explain to me, how in the event of PM_EVT_STORAGE_FULL simply running the fds_gc() without deleting old peers data will the system have space to new bond?

    Probably not, because an attacker can now force you to delete your bonding. But we know nothing about your application...

    My question wasn't about security, but if it is safe regarding the requirement not to erase during connectable/connected state.

    The peer manager has a ranking function that one could use in order to determine the newst/oldest peer for deletion.

    Can you explain how that works?

Reply
  • Your assumtion is wrong. Please re-read the chapter on how fds works: It keeps stale data next to "current" data records. This could exaust your flash pages, even when most of the space in each page is "stale".

    According to here:

    "FDS relies on garbage collection to reclaim flash space used by records that have been invalidated....... if there are any dirty records in flash which can be garbage collected."

    As far as I understand previously bonded devices information is not invalidated and not "dirty" so why will the garbage collector reclaim this space?

    And as response to question #2 here:

    "You can check whether there are deleted records in flash, using fds_stat() for instance. If fds_gc() does not free enough space, then the record cannot fit in flash: the flash is full. You have to delete something and run GC."

    So, please explain to me, how in the event of PM_EVT_STORAGE_FULL simply running the fds_gc() without deleting old peers data will the system have space to new bond?

    Probably not, because an attacker can now force you to delete your bonding. But we know nothing about your application...

    My question wasn't about security, but if it is safe regarding the requirement not to erase during connectable/connected state.

    The peer manager has a ranking function that one could use in order to determine the newst/oldest peer for deletion.

    Can you explain how that works?

Children
No Data
Related