BLE sequence of characteristic discovery and read with and without pairing/bonding

RE: BLE sequence of characteristic discovery and read with and without pairing/bonding

Hung Bui — Fri, 30 Sep 2022 07:44:01 GMT

Hi Mike,

Sorry for the late response. I haven't fully tested CONFIG_BT_KEYS_OVERWRITE_OLDEST but from what I can see in the code it seems that the oldest bond (most aged) will get removed automatically by bt_unpair() in keys.c :

Have you tried to test by just enabling CONFIG_BT_KEYS_OVERWRITE_OLDEST ?

Regarding your question about having the central remove bond but the bond remains on the peripheral, it's about security requirement. There is a risk that an attacker can spoof that it's the central and request a new bond. So usually it's not allowed to request a new bond from a bonded central.
You will need to handle it with some extra security requirement, for example a physical button to erase all bonds (or single bond) , and you can call bt_unpair() in the code. In nRF5 SDK we have the allow_repair option, but I haven't seen the same option in Zephyr.
But it's possible to allow repair if it's JustWork pairing, you can use this config: CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE

RE: BLE sequence of characteristic discovery and read with and without pairing/bonding

Mike Austin (LPI) — Thu, 29 Sep 2022 01:09:30 GMT

OK, sorted it. CONFIG_BT_MAX_PAIRED was set to 1. Just increased that to 5 (I have 8192 bytes of flash storage for bonding/pairing info, so could potentially increase that a fair bit more) and I can get my peripheral to correctly grab the CTS from multiple clients now.

I now want to ensure I don't end up hitting the limit of CONFIG_BT_MAX_PAIRED, so want to check the actual number of centrals paired at any given moment, and start removing earlier ones (or just wiping the whole lot clean) to keep below the limit.

There appears to be a config setting CONFIG_BT_KEYS_OVERWRITE_OLDEST that if enabled, should allow the system to overwrite the oldest bonding/pairing info when it hits the CONFIG_BT_MAX_PAIRED limit. I can see a bunch of API's in keys.c that manage the overwriting, but its not clear how I get these to be implemented. Is this something the code takes care of by simply setting CONFIG_BT_KEYS_OVERWRITE_OLDEST=y? Or do I actually need to be calling those API's within my own code to manage the BT keys?

I'm also trying to deal with the scenario where a central deletes the bonding information but this still remains within the peripheral. At the moment, my code fails to work correctly if this happens, so I need someway of detecting this (I think its when I get a Reason 4 return from my pairing_failed() function.

Cheers,

Mike

RE: BLE sequence of characteristic discovery and read with and without pairing/bonding

Mike Austin (LPI) — Wed, 28 Sep 2022 23:46:18 GMT

Hi Hung,

I've been doing a bit more development work on the CTS functionality. Your suggestion above seems to work, but only if I am accessing my peripheral with the same client.

If I introduce a new client, then the whole bonding/pairing scenario for the new client doesn't appear to be functioning as I would expect, and my code jumps into attempting to grab the CTS info without bonding/pairing to the new client. And this ultimately fails.

Any ideas how I can check within my code whether my peripheral has paired/bonded with a specific client, and if not, set up a new pairing/bonding with that client?

Cheers,

Mike

RE: BLE sequence of characteristic discovery and read with and without pairing/bonding

Mike Austin (LPI) — Thu, 15 Sep 2022 23:15:01 GMT

Hi Hung,

Yep - using NCS V2.0.0, so your suggestion worked. Thanks for your help

Cheers,

Mike

RE: BLE sequence of characteristic discovery and read with and without pairing/bonding

Hung Bui — Mon, 22 Aug 2022 12:57:00 GMT

Hi Mike,

Could you let me know which SDK version you are using ?
If you are using NCS v2.0.x you can have a look at the periphera_uart example.
In the example, if you enable CONFIG_BT_NUS_SECURITY_ENABLED, you can find that:

- On the first bond, after the bonding is finished, you will receive pairing_complete() call back.

- On reconnection to a bonded device, you will not receive pairing_complete() but instead receive security_changed() call back. Note that security_changed belong to conn_callbacks when the pairing_complete() belongs to conn_auth_info_callbacks