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 Biliy, 

I believe it's not a bug but a feature. 
When you connect to a previously bonded device and the device now has removed bond with you, you are not expected to remove the previous bond and remove the gatt cache (CCCD cache) 
The reason for that is that an attacker can easily spoof the peer device address and pretend that the bond has been removed (and maybe request a new bond). 

You can either allow overwriting using this config CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE (only for just work) or request end user proactively remove bond on the device itself. 

So from my point of view GATT cache should not be automatically removed. It should only be remove when delete bond button is pressed/selected on the device itself. 

[vitaliy2034]

Thank you for your reply. I agree with your argument, but this behavior creates a situation where the peripheral device is bonded, and the client is not (bonds are lost, for example, because of application data reset). After that, the same client initiates the pairing again, as it thinks, with a new device. After reconnecting, the peripheral device loads the old (previous) connection with the old CCCD values, but the client assumes it has connected to a new device and does not expect these CCCD values, which, in our case, causes unexpected notifications and, as a result, the client's BLE stack to get stuck.

Please advise the proper way to handle this situation. Maybe there is some way to check if the client has bonds?

I've also tried to send a peripheral security request but got the same behavior.

[vitaliy2034]

Hi Hung and Emil, thank you both for the detailed responses, and apologies for the late reply.

I completely agree that checking the security level before sending notifications or indications is a good safeguard. However, even when the required security level is enforced, the core issue of CCCD desynchronization between the peripheral and central still persists — and that’s where my main concern lies.

To clarify further: even if, after the central deletes the bond, I reconnect  (as in step 5) and perform a new pairing and bonding additionally, the peripheral still attempts to send indications on value update, based on the old CCCD state that was cached from the previous bond. This happens before the central has explicitly enabled indications in the current session.

According to the Bluetooth specification, a peripheral must not send notifications or indications unless the client has enabled them via the CCCD. 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.

So the key question remains:
What is the correct and recommended way to handle(on peripheral or central side) or reset the CCCD state when the bond has been removed on the central side but still exists on the peripheral?

Any clarification or best practice from Nordic would be very helpful.

[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!