Bluetooth link key settings management possibilities

[benedekkupper]

Dear community!

We are developing a BLE product with zephyr, that bonds to the central devices. Our team often runs into issues when pairing the device with this error:

Connected to unknown (aa:aa:aa:aa:aa:aa)
Disconnected from unknown (aa:aa:aa:aa:aa:aa), reason 19

Which is a very nondescript way of saying "sorry, cannot pair as there are no free settings slots for storing a new Bluetooth link key". The first possible improvement here would be giving a better error description in the logs.

Now onto the more difficult part. What are our options to remove this roadblock of pairing a new device in this scenario? So far the only possibility I found (through #55475) is to delete all existing pairings. This is obviously very counterproductive overall. My preferred solution would be to update a timestamp on each key with the last connection time, and delete the key which is the oldest, but I don't think this is supported by the current API or system design in general. I'd like to hear from you what are the current possibilities, and what possibilities are within reach, given the current architecture (only missing an API chain without rework of the existing system).

Finally, I'm also aware of the existence of the Bond Management Service, and I've seen that zephyr / nRF SDK has support for this service. Does anyone have real-world experience with this service in use though? It would be nice to use this service to solve the problem (even if it's creating extra inconvenience for the user), but it seems that this isn't supported on the central side in any major OS.

Thanks in advance

[kvanbere]

Maybe it is possible to increase the number of stored keys to a very large number?

[nordicjm]

Which is a very nondescript way of saying "sorry, cannot pair as there are no free settings slots for storing a new Bluetooth link key". The first possible improvement here would be giving a better error description in the logs.

That error output is from your application though? If you wanted to add a descriptive log, you can implement that

My preferred solution would be to update a timestamp on each key with the last connection time, and delete the key which is the oldest, but I don't think this is supported by the current API or system design in general.

Have you looked at CONFIG_BT_KEYS_OVERWRITE_OLDEST ?

[benedekkupper]

Have you looked at CONFIG_BT_KEYS_OVERWRITE_OLDEST ?

This seems pretty close to what I'm looking for, indeed, thanks for the hint! I have some follow-up questions to this though:

1. I found another Kconfig option: BT_KEYS_SAVE_AGING_COUNTER_ON_PAIRING, which saves the aging counter on each pairing. Do I understand correctly, that with this option the "oldest" that is overwritten is the key that wasn't in use for the longest time? And without this option, CONFIG_BT_KEYS_OVERWRITE_OLDEST overwrites the "oldest" from the time of creation?
2. I took some time to scour through this Kconfig file, another interesting option I found was CONFIG_BT_ID_UNPAIR_MATCHING_BONDS, which has a long description, but still not very clear for me what it actually does. A major problem with how Bluetooth bonding works is one side doesn't know if the other "forgot" the pair device, and the useless key is left in settings. My understanding is that with this option on, if a central device is re-pairing (creating a new link key), any old key that was previously stored for the same central device will be removed, do I get that right?

[nordicjm]

I think that is correct for 1.
For 2 that means the zephyr device will not care if a device connects that already has a bond and re-pairs, it actually is a security risk, which is why a phone will not do that and instead requires you manually go and delete a bond if the other device has done the same before it allows you to connect.

If you don't need bonding then you can safely disable it and pair each time you connect which means you still have security but don't have to worry about bonds being deleted