BLE stack loads old CCCD values after removing bonds on client side and reconnect

[vitaliy2034]

I'm testing BLE secure communication with the nRF52840DK device and I have encountered a problem with bonds. I use modified example from BLE fundamental course, in which I added ability to determine if we connected to new or bonded client. The following steps will better describe my issue:

1. Perform connection, pairing, and bonding with the nRF52840DK(Nordic_LBS).
   
2. Subscribe to Button characteristic notification(write to its CCCD 0x0001 value).
   
3. Disconnect from nRF52840DK(Nordic_LBS).
4. Remove bonds on the client's side. (Bonds on nRF52840DK(Nordic_LBS) still present):
   
5. Perform connection with the same nRF Connect client. As you can see, nRF52840DK(Nordic_LBS) still assume that it bonded with client.
   
6. Check Button characteristic CCCD value.

Expected result: 0x0000

Actual result: 0x0001

Same situation occurs even if in step 5 I perform connection, pairing, bonding again with the device. nRF connect logs and modified example attached.

Fullscreen nRF Connect Logs.txt Download

nRF Connect, 2025-04-29
Nordic_LBS (C5:9D:AD:DC:BB:A3)
V	10:54:20.015	Connecting to C5:9D:AD:DC:BB:A3...
D	10:54:20.015	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	10:54:20.300	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	10:54:20.301	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	10:54:20.301	Connected to C5:9D:AD:DC:BB:A3
V	10:54:20.302	Discovering services...
D	10:54:20.302	gatt.discoverServices()
D	10:54:20.425	[Callback] Services discovered with status: 0
I	10:54:20.425	Services discovered
V	10:54:20.426	Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
- Client Supported Features [R W] (0x2B29)
- Database Hash [R] (0x2B2A)
Generic Access (0x1800)
- Device Name [R] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Nordic LED Button Service (00001523-1212-efde-1523-785feabcd123)
- Button [N R] (00001524-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
- LED [W] (00001525-1212-efde-1523-785feabcd123)
D	10:54:20.426	gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D	10:54:20.427	gatt.setCharacteristicNotification(00001524-1212-efde-1523-785feabcd123, true)
I	10:54:20.983	PHY updated (TX: LE 2M, RX: LE 2M)
V	10:54:22.807	Starting pairing...
D	10:54:22.807	device.createBond()
D	10:54:22.872	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BONDING (11)
D	10:54:23.016	[Broadcast] Action received: android.bluetooth.device.extra.PAIRING_VARIANT, pairing variant: PIN
I	10:54:25.497	Connection parameters updated (interval: 47.5ms, latency: 0, timeout: 420ms)
D	10:54:40.213	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BONDED (12)
I	10:54:40.213	Device bonded
V	10:55:08.990	Enabling notifications for 00001524-1212-efde-1523-785feabcd123
D	10:55:08.990	gatt.setCharacteristicNotification(00001524-1212-efde-1523-785feabcd123, true)
D	10:55:08.992	gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x0100)
I	10:55:09.054	Data written to descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
A	10:55:09.054	"Notifications enabled" sent
V	10:55:09.056	Notifications enabled for 00001524-1212-efde-1523-785feabcd123
V	10:55:23.185	Reading descriptor 00002902-0000-1000-8000-00805f9b34fb
D	10:55:23.185	gatt.readDescriptor(00002902-0000-1000-8000-00805f9b34fb)
I	10:55:23.256	Read Response received from descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
A	10:55:23.256	"Notifications enabled" received
V	10:56:07.030	Disconnecting...
D	10:56:07.030	gatt.disconnect()
D	10:56:07.037	[Callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
I	10:56:07.037	Disconnected
D	10:56:08.067	[Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
V	10:58:35.899	Removing bond information...
D	10:58:35.899	device.removeBond() (hidden)
D	10:58:35.983	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: NONE (10), reason: REMOVED (9)
I	10:58:35.983	Bond information lost, reason: REMOVED (9)
D	10:58:37.758	gatt.close()
D	10:58:37.761	wait(200)
V	10:58:37.964	Connecting to C5:9D:AD:DC:BB:A3...
D	10:58:37.964	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	10:58:38.219	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	10:58:38.235	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	10:58:38.235	Connected to C5:9D:AD:DC:BB:A3
V	10:58:38.254	Discovering services...
D	10:58:38.254	gatt.discoverServices()
D	10:58:38.346	[Callback] Services discovered with status: 0
I	10:58:38.346	Services discovered
V	10:58:38.349	Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
- Client Supported Features [R W] (0x2B29)
- Database Hash [R] (0x2B2A)
Generic Access (0x1800)
- Device Name [R] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Nordic LED Button Service (00001523-1212-efde-1523-785feabcd123)
- Button [N R] (00001524-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
- LED [W] (00001525-1212-efde-1523-785feabcd123)
D	10:58:38.349	gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D	10:58:38.355	gatt.setCharacteristicNotification(00001524-1212-efde-1523-785feabcd123, true)
I	10:58:38.910	PHY updated (TX: LE 2M, RX: LE 2M)
I	10:58:43.424	Connection parameters updated (interval: 47.5ms, latency: 0, timeout: 420ms)
V	10:58:53.575	Reading descriptor 00002902-0000-1000-8000-00805f9b34fb
D	10:58:53.575	gatt.readDescriptor(00002902-0000-1000-8000-00805f9b34fb)
I	10:58:53.636	Read Response received from descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
A	10:58:53.636	"Notifications enabled" received
D	10:58:53.639	gatt.setCharacteristicNotification(00001524-1212-efde-1523-785feabcd123, true)
V	10:58:53.641	Notifications enabled for 00001524-1212-efde-1523-785feabcd123

l6_e3_sol.zip

Please advise if it is possible to handle that situation on the side. Or should it be handled on the client side and how?

[Hung Bui]

Hi Billy, 
As far as I know Zephyr won't allow a re-pairing with the same central (unless you configured so, and only applied for Justwork). 

As mentioned earlier, the way it should work in my opinion is that when the central deletes bond, the peripheral need to delete the bond to the same central as well. How the peripheral delete bond depend on the design choice, either having a physical button or having an encrypted command (proprietary) to erase bond. 

Could you describe how you did this " I reconnect  (as in step 5) and perform a new pairing and bonding additionally, the peripheral still attempts to send indications on value update, " ? 

[Emil Lenngren]

"When this desynchronization occurs, the behavior becomes unpredictable. In my case, when connecting to a commercial device, this mismatch sometimes freezes the BLE stack, regardless of whether the connection is encrypted or not."

This doesn't seem that good. What BLE stack do you have that it is this buggy? The BLE spec says in the same chapter, section 10.3.2.2, that "Any notifications received before the security requirements are met shall be ignored."

The BLE spec doesn't seem to discuss your particular case though. Per the BLE spec, it is theoretically possible that the client did not remove the bond but just wanted to upgrade the security level of its bond by sending a Pairing request, before encryption using the old LTK has been started (see flow chart figure 10.2 in the same chapter), right after the server sent a Peripheral Security Request with the intention to start encryption of the existing LTK rather than pairing. Unfortunately, it is impossible for the peripheral to distinguish between a new bond and an upgraded bond in case the new requested security level is higher than the old one. So, if a client receives unsolicited notifications, the most appropriate action seems to be to just ignore them. The client could also write 0x0000 to the CCCD an extra time in case it is unsynchronised.

That said, if the peripheral receives a Pairing request from a central when a bond already exists, which does not request a higher security level than what is already present in the current bond, it can assume that it is a new bond. In particular, if the peripheral only allows pairing at the highest security level (LESC + MITM with 128-bit key) at all times, it can safely assume it is not an upgrade but a new bond. In that case (assuming the user, after confirmation, even allows a new bond in this case), the peripheral should reset all CCCDs to the default value (0x0000).

In order to synchronise bond removal, you can use the https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/bluetooth/services/bms.html BMS standard service. But both sides need to implement it in order for it to be useful.

[vitaliy2034]

Hi Hung,

To perform a new pairing, I pressed the "Bond" button again in the nRF Connect app after reconnecting in step 5:

And after that, the pairing completes successfully:

[vitaliy2034]

Hi Emil,
Thank you very much for your detailed reply.

For testing, we are using automated scripts that control a Nordic dongle, which has been flashed with a modified BLE Interactive Command Line Interface Example.

If I understand you correctly, there is currently no straightforward solution officially recommended by the Bluetooth SIG for this particular case.

Could you also please confirm if I have correctly understood your suggested possible solutions:

1. The client should ignore any unsolicited indications/notifications from the peripheral if it did not subscribe to them.

2. If the peripheral receives a pairing request from the central while a bond already exists, and the requested security level is not higher than the existing bond, the peripheral can treat this as a new bond and reset all relevant data.

3. As an alternative, both devices can implement the Bluetooth BMS (Bond Management Service) to synchronize bond removal.

Additionally, I have a clarification question regarding option 2:
If a new bond is detected in this way, should the application explicitly reset the CCCD values to 0x0000 in the peripheral firmware, or does the Nordic BLE stack automatically handle the CCCD reset when a new bond replaces the old one?

Thank you again for your help and clarification!

[Hung Bui]

Hi Biliy, 
Actually you are right about overwriting bond. I was under the impression that it's not possible but it's actually is if the bond is higher level than level 2 (Just Work). 
So only for Just work it's disabled by default and can be enable with CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE. But for bonding with MITM it seems that re-bond is allowed. 

I will check internally to see if there is an option to disable that. 

Resetting the CCCD value after a new bond would be a good option. It's the server that store the CCCD's value, so the client either need to read the value of the CCCD to know if it should expect notification or reset it with a write.