nRF Connect for Mac Desktop loses bond information when closed

[Saxman58]

I am using the nRF Connect 3.6.0 Bluetooth Low Energy app v2.4.2 on MacOS.  When I pair and bond with my device it works fine.  I can disconnect and connect in the same session, and nRF Connect remembers the device (and the device has stored its bonding info too with the peer manager) and establishes an unauthenticated (by design) encrypted connection.  But if I close nRF Connect, it loses the bonding information.  When I restart it, the device remembers it from its bonding table, but nRF Connect does not, and does not try to establish an encrypted connection.

I have verified this with Wireshark.  Everything looks fine after initial bonding as long as I don't close nRF Connect.  I can disconnect and reconnect, and every time the master (nRF Connect) will send an LL_ENC_REQ packet to start the process of changing to an encrypted link.  But if I close and reopen nRF Connect, it never sends the LL_ENC_REQ, as if its bonding table has been erased.

Where are nRF Connect's bonds stored?  I can't find a file like this in the Application Support folder (where the log uuid_definitions.json file are stored).  Are they on the scanning device (in this case an nRF52840 dongle)?  Why are they not persistent, or are they not stored anywhere?

[tesc]

Hi,

nRF Connect for Desktop does not store bonds. The behavior that you see is as expected. Do you have a use case where storing the bond across nRF Connect sessions is needed?

Regards,
Terje

[Saxman58]

Our product requires pairing to write most attributes, and our use-case will be primarily be long term pairing of one device to one host.  So bonding and automatic pairing on connect will be the norm.  All host apps I've seen before store bonds, so I was assuming that Connect did too.

We can form a new bond for each testing session, so there is a workaround.  But I assumed that Connect would act like most host applications and store the information.  So I spent a few hours trying to find a bug in my firmware before I checked the communications with Wireshark and realized it was a Connect issue.  I'm concerned that our product testers (who are using Connect until our own host software is further along) will also think there is a bug in my firmware.

I would recommend that the Connect app makes it more obvious when it has some bonds stored.  For example, the "Delete bond information" could be greyed out when there are no bonds.  Or it could show a count of the stored bonds such as "Delete 1 bond", or "Delete bond to [address]".

[tesc]

Hi,

Thank you for the feedback and suggestions. I will forward it to the team. It could clearly be more obvious, yes.

nRF Connect is primarily intended as a development tool. For testing one would probably want an automated setup e.g. a custom application built on top of pc-ble-driver (serializing the SoftDevice) or similar.

Regards,
Terje