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.

[Hung Bui]

Hi Biliy, 

I was thinking of the encryption property of the characteristic would help preventing the notification but it's not true. Even if the connection doesn't meet the encryption requirement of the characteristic , the notification will still be sent if the cache used. 

My suggestion is to add a check for the current security level of the connection before sending the notification. This way even if the CCCD is set, you can avoid having the notification being sent when the link is not encrypted at the correct level. 

[Emil Lenngren]

The Bluetooth 6.0 spec says the following (Vol 3: Host, Part C: Generic Access Profile, 10.3.1.1):

Handling of GATT indications and notifications

A client “requests” a server to send indications and notifications by appropriately configuring the server via a Client Characteristic Configuration Descriptor. Since the configuration is persistent across a disconnection and reconnection, security requirements shall be checked against the configuration upon a reconnection before sending indications or notifications. When a server reconnects to a client to send an indication or notification for which security is required, the server shall initiate or request encryption with the client prior to sending an indication or notification. If the client does not have an LTK, indicating that the client has lost the bond, enabling encryption will fail.

So yes, if the server is the peripheral role and encryption has not yet been enabled, it should send a Peripheral Security Request, wait for encryption started OR pairing completion (assuming the peripheral allows re-pair attempts at this point, perhaps after user consent) with sufficient security level, THEN send the characteristic notification.

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