Bluetooth: Host: Bonding with the same Central using multiple identities #2963

PavelVPV · 2025-06-17T19:04:21Z

This PR adds a feature to allow bonding with the same Central using multiple identities.

The PR consists of 2 commits.

The first commit adds a new Kconfig option by enabling which Host will keep
bonding with the same Central instead of rejecting pairing.

Brief implementation details:

This implementation adds a new flag to bt_keys struct:
BT_KEYS_ID_CONFLICT. The flag is set, when:

bonding with the same peer and conflict identified
when loading conflicting keys from persistent storage.

When bonding and conflict is identified, the new keys aren't added to
the Resolving List immediately. Instead, the old keys stay in the
Resolving List.

When start advertising, Host finds conflicting keys that are already
added to the Resolving List and substitues them.

If, however, there is another advertiser already started for the added
keys, the new request is reject and advertising start function returns
-EPERM.

The second adds the following tests:

a test that checks undirected advertisements
a test that checks directed advertisements
a test that checks undirected advertisement with the Filter Accept List
a test that checks unpairing
a test that checks start of multiple advertisements in parallel
a test that checks recovering BT_KEYS_ID_CONFLICT after reboot

PavelVPV · 2025-06-17T19:10:53Z

subsys/bluetooth/host/Kconfig

+	bool "Automatically swap conflicting entries in the Resolving List"
+	depends on !BT_ID_UNPAIR_MATCHING_BONDS
+	depends on BT_PRIVACY && BT_PERIPHERAL && !BT_CENTRAL
+	select EXPERIMENTAL


Not sure if I need to keep this option as experimental.

I think experimental should be removed as this goes into production by customer.

alxelax · 2025-06-19T08:14:55Z

Just curious how are implemented bsim tests going to be checked if CI bsim in downstream isn't run?

PavelVPV · 2025-06-19T08:37:21Z

Just curious how are implemented bsim tests going to be checked if CI bsim in downstream isn't run?

Manually

PavelVPV · 2025-06-19T09:03:55Z

Added persistent storage test to verify that re-connection works fine after recovering bonding data from flash.

KyraLengfeld · 2025-06-19T12:21:19Z

subsys/bluetooth/host/id.c

 struct bt_id_conflict {
 	struct bt_keys *candidate;
 	struct bt_keys *found;
+	bool all;


Only one nitpick: all seems to me a bit ambiguous. Perhaps better to call it check_all_irk or similar? Feel free to disregard. Otherwise to me this PR looks good, although with the caveat that I am still lacking quite some knowledge of the host, nor did I manually run the bsim tests you added to check.

subsys/bluetooth/host/adv.c

omkar3141 · 2025-06-24T09:58:25Z

subsys/bluetooth/host/Kconfig

@@ -630,6 +630,24 @@ config BT_ID_UNPAIR_MATCHING_BONDS
 	  link-layer. The Host does not have control over this acknowledgment,
 	  and the order of distribution is fixed by the specification.

+config BT_ID_AUTO_SWAP_MATCHING_BONDS
+	bool "Automatically swap conflicting entries in the Resolving List"
+	depends on !BT_ID_UNPAIR_MATCHING_BONDS


I think "!BT_CENTRAL" is unnecessary. You may have central which is dealing with other non-private connections with other peripherals, and that would work without any issues.

I don't even want to think what will happen if BT_CENTRAL is enabled. The current use case is for Peripheral role only. Therefore it is easier to prevent compiling with BT_CENTRAL. If a customer comes with request to support Central role as well, we will look at this again.

PavelVPV · 2025-06-24T21:20:40Z

Addressed comments. Also found bug when removing last conflicting key during unpairing.

PavelVPV · 2025-06-25T19:34:18Z

Test commit is dropped. Tests are moved to the internal test framework.

omkar3141

unrelated: bt_le_adv_start_ext could be made static.

Balaklaka

Some of the github actions should be fixed.

Balaklaka · 2025-06-26T09:04:50Z

subsys/bluetooth/host/Kconfig

+	bool "Automatically swap conflicting entries in the Resolving List"
+	depends on !BT_ID_UNPAIR_MATCHING_BONDS
+	depends on BT_PRIVACY && BT_PERIPHERAL && !BT_CENTRAL
+	select EXPERIMENTAL


I think experimental should be removed as this goes into production by customer.

subsys/bluetooth/host/Kconfig

subsys/bluetooth/host/id.c

subsys/bluetooth/host/smp.c

subsys/bluetooth/host/id.c

This commit adds a new Kconfig option by enabling which Host will keep bonding with the same Central instead of rejecting pairing. Brief implementation details: This implementation adds a new flag to bt_keys struct: BT_KEYS_ID_CONFLICT. The flag is set, when: - bonding with the same peer and conflict identified - when loading conflicting keys from persistent storage. When bonding and conflict is identified, the new keys aren't added to the Resolving List immediately. Instead, the old keys stay in the Resolving List. When start advertising, Host finds conflicting keys that are already added to the Resolving List and substitues them. If, however, there is another advertiser already started for the added keys, the new request is reject and advertising start function returns -EPERM. This is supported by Peripheral role only for now. Signed-off-by: Pavel Vasilyev <[email protected]>

sonarqubecloud · 2025-06-26T13:22:38Z

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

NordicBuilder mentioned this pull request Jun 17, 2025

manifest: sdk-zephyr: Bluetooth: Host: Bonding with the same Central using multiple identities nrfconnect/sdk-nrf#22850

Open

PavelVPV commented Jun 17, 2025

View reviewed changes

PavelVPV force-pushed the multi_id_bond branch 3 times, most recently from 358652b to 024e250 Compare June 17, 2025 19:50

PavelVPV force-pushed the multi_id_bond branch 2 times, most recently from 187ccc8 to 92987f9 Compare June 19, 2025 09:03

PavelVPV force-pushed the multi_id_bond branch from 92987f9 to 9e58e65 Compare June 19, 2025 09:18

KyraLengfeld approved these changes Jun 19, 2025

View reviewed changes

alwa-nordic reviewed Jun 23, 2025

View reviewed changes

subsys/bluetooth/host/adv.c Outdated Show resolved Hide resolved

omkar3141 reviewed Jun 24, 2025

View reviewed changes

PavelVPV force-pushed the multi_id_bond branch from 9e58e65 to 4ca09e1 Compare June 24, 2025 21:19

PavelVPV force-pushed the multi_id_bond branch 2 times, most recently from 750b10f to 447cebe Compare June 25, 2025 19:33

PavelVPV requested review from alwa-nordic, omkar3141 and KyraLengfeld June 26, 2025 07:47

omkar3141 approved these changes Jun 26, 2025

View reviewed changes

Balaklaka reviewed Jun 26, 2025

View reviewed changes

PavelVPV force-pushed the multi_id_bond branch from 447cebe to d82c139 Compare June 26, 2025 12:49

PavelVPV requested a review from Balaklaka June 26, 2025 12:51

PavelVPV force-pushed the multi_id_bond branch 2 times, most recently from aeab23c to 966aa7a Compare June 26, 2025 13:02

PavelVPV force-pushed the multi_id_bond branch from 966aa7a to c187a92 Compare June 26, 2025 13:15

Balaklaka approved these changes Jun 26, 2025

View reviewed changes

Bluetooth: Host: Bonding with the same Central using multiple identities #2963

Are you sure you want to change the base?

Bluetooth: Host: Bonding with the same Central using multiple identities #2963

Conversation

PavelVPV commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PavelVPV Jun 17, 2025

Choose a reason for hiding this comment

Uh oh!

Balaklaka Jun 26, 2025

Choose a reason for hiding this comment

Uh oh!

alxelax commented Jun 19, 2025

Uh oh!

PavelVPV commented Jun 19, 2025

Uh oh!

PavelVPV commented Jun 19, 2025

Uh oh!

KyraLengfeld Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

omkar3141 Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

PavelVPV Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

PavelVPV commented Jun 24, 2025

Uh oh!

PavelVPV commented Jun 25, 2025

Uh oh!

omkar3141 left a comment

Choose a reason for hiding this comment

Uh oh!

Balaklaka left a comment

Choose a reason for hiding this comment

Uh oh!

Balaklaka Jun 26, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Jun 26, 2025

Quality Gate failed

Uh oh!

Uh oh!

PavelVPV commented Jun 17, 2025 •

edited

Loading