[PATCH v2] Bluetooth: find an RPA peer's connection parameters by its identity

[PATCH v2] Bluetooth: find an RPA peer's connection parameters by its identity

[Radek Podgorny]

A bonded peer's connection parameters are stored under its identity
address, but hci_conn_params_lookup() matches only the exact address it
is given, so a caller holding the peer's RPA misses the entry.

hci_le_create_conn_sync() is such a caller: hci_connect_le() puts the
peer's cached RPA in conn->dst, and __hci_conn_add() no longer converts
it back when the controller cannot translate an identity address. The
connection is then created with the controller-wide defaults in hdev
instead of the peer's interval, latency and supervision timeout.

Resolve the RPA in hci_conn_params_lookup() when the exact match fails,
so every caller finds the same entry whichever of the peer's addresses
it holds. The exact match is tried first, so an entry stored under an
RPA is still found as before.

hci_conn_params_add() and hci_conn_params_del() look up through the
same function, so given a resolvable RPA they now act on the peer's
identity entry instead of creating or missing a separate one.

Fixes: 4914c4998961 ("Bluetooth: put the peer's on-air address on air when we cannot resolve")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Radek Podgorny <radek@podgorny.cz>
---
Changes in v2:
- Resolve the RPA inside hci_conn_params_lookup() rather than at the
  hci_le_create_conn_sync() call site, as Luiz suggested, so no other
  caller can miss the entry
- Exact match still first, so entries stored under an RPA are unchanged.
  I weighed inlining this as one pass matching either address, but that
  lets list order rather than exactness decide between an RPA entry and
  an identity entry, and resolves the IRK on every RPA lookup; a small
  helper scanned twice seemed cleaner
- Rebased on bluetooth-next
- Link to v1: https://patch.msgid.link/20261101-for-upstream-le-conn-params-rpa-v1-1-988629a09bc9@podgorny.cz

Tested on the author's van (BCM4345C0 against a bonded peer that
rotates RPAs): with v2 the peer's stored connection parameters are used
again. bluetooth-next itself was only build-tested.

Per Documentation/process/generated-content.rst: the patch and this
message were done with the Claude coding assistant (model as in the
Assisted-by trailer). The prompts asked it to fix the lookup miss named
in the on-air address review and, for v2, to move the fix into
hci_conn_params_lookup() per review. The author directed the work,
reviewed the result and tested it on the van.
---
 net/bluetooth/hci_core.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bfc5bdebc71a2..2dc12c01c4dc1 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2285,9 +2285,8 @@ int hci_bdaddr_list_del_with_irk(struct list_head *list, bdaddr_t *bdaddr,
 	return 0;
 }
 
-/* This function requires the caller holds hdev->lock */
-struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
-					       bdaddr_t *addr, u8 addr_type)
+static struct hci_conn_params *conn_params_find(struct hci_dev *hdev,
+						bdaddr_t *addr, u8 addr_type)
 {
 	struct hci_conn_params *params;
 
@@ -2301,6 +2300,27 @@ struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
 	return NULL;
 }
 
+/* This function requires the caller holds hdev->lock */
+struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
+					       bdaddr_t *addr, u8 addr_type)
+{
+	struct hci_conn_params *params;
+	struct smp_irk *irk;
+
+	params = conn_params_find(hdev, addr, addr_type);
+	if (params)
+		return params;
+
+	/* A bonded peer's parameters are stored under its identity address,
+	 * so an RPA that resolves to it finds the same entry.
+	 */
+	irk = hci_get_irk(hdev, addr, addr_type);
+	if (!irk)
+		return NULL;
+
+	return conn_params_find(hdev, &irk->bdaddr, irk->addr_type);
+}
+
 /* This function requires the caller holds hdev->lock or rcu_read_lock */
 struct hci_conn_params *hci_pend_le_action_lookup(struct list_head *list,
 						  bdaddr_t *addr, u8 addr_type)

base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db
-- 
2.56.0

Re: [PATCH v2] Bluetooth: find an RPA peer's connection parameters by its identity

[Luiz Augusto von Dentz]

Hi Radek,

On Wed, Nov 4, 2026 at 7:07 AM Radek Podgorny <radek@podgorny.cz> wrote:
>
> A bonded peer's connection parameters are stored under its identity
> address, but hci_conn_params_lookup() matches only the exact address it
> is given, so a caller holding the peer's RPA misses the entry.
>
> hci_le_create_conn_sync() is such a caller: hci_connect_le() puts the
> peer's cached RPA in conn->dst, and __hci_conn_add() no longer converts
> it back when the controller cannot translate an identity address. The
> connection is then created with the controller-wide defaults in hdev
> instead of the peer's interval, latency and supervision timeout.
>
> Resolve the RPA in hci_conn_params_lookup() when the exact match fails,
> so every caller finds the same entry whichever of the peer's addresses
> it holds. The exact match is tried first, so an entry stored under an
> RPA is still found as before.
>
> hci_conn_params_add() and hci_conn_params_del() look up through the
> same function, so given a resolvable RPA they now act on the peer's
> identity entry instead of creating or missing a separate one.
>
> Fixes: 4914c4998961 ("Bluetooth: put the peer's on-air address on air when we cannot resolve")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Radek Podgorny <radek@podgorny.cz>
> ---
> Changes in v2:
> - Resolve the RPA inside hci_conn_params_lookup() rather than at the
>   hci_le_create_conn_sync() call site, as Luiz suggested, so no other
>   caller can miss the entry
> - Exact match still first, so entries stored under an RPA are unchanged.
>   I weighed inlining this as one pass matching either address, but that
>   lets list order rather than exactness decide between an RPA entry and
>   an identity entry, and resolves the IRK on every RPA lookup; a small
>   helper scanned twice seemed cleaner
> - Rebased on bluetooth-next
> - Link to v1: https://patch.msgid.link/20261101-for-upstream-le-conn-params-rpa-v1-1-988629a09bc9@podgorny.cz
>
> Tested on the author's van (BCM4345C0 against a bonded peer that
> rotates RPAs): with v2 the peer's stored connection parameters are used
> again. bluetooth-next itself was only build-tested.
>
> Per Documentation/process/generated-content.rst: the patch and this
> message were done with the Claude coding assistant (model as in the
> Assisted-by trailer). The prompts asked it to fix the lookup miss named
> in the on-air address review and, for v2, to move the fix into
> hci_conn_params_lookup() per review. The author directed the work,
> reviewed the result and tested it on the van.
> ---
>  net/bluetooth/hci_core.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index bfc5bdebc71a2..2dc12c01c4dc1 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2285,9 +2285,8 @@ int hci_bdaddr_list_del_with_irk(struct list_head *list, bdaddr_t *bdaddr,
>         return 0;
>  }
>
> -/* This function requires the caller holds hdev->lock */
> -struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
> -                                              bdaddr_t *addr, u8 addr_type)
> +static struct hci_conn_params *conn_params_find(struct hci_dev *hdev,
> +                                               bdaddr_t *addr, u8 addr_type)
>  {
>         struct hci_conn_params *params;
>
> @@ -2301,6 +2300,27 @@ struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
>         return NULL;
>  }
>
> +/* This function requires the caller holds hdev->lock */
> +struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
> +                                              bdaddr_t *addr, u8 addr_type)
> +{
> +       struct hci_conn_params *params;
> +       struct smp_irk *irk;
> +
> +       params = conn_params_find(hdev, addr, addr_type);
> +       if (params)
> +               return params;
> +
> +       /* A bonded peer's parameters are stored under its identity address,
> +        * so an RPA that resolves to it finds the same entry.
> +        */
> +       irk = hci_get_irk(hdev, addr, addr_type);
> +       if (!irk)
> +               return NULL;
> +
> +       return conn_params_find(hdev, &irk->bdaddr, irk->addr_type);
> +}
> +
>  /* This function requires the caller holds hdev->lock or rcu_read_lock */
>  struct hci_conn_params *hci_pend_le_action_lookup(struct list_head *list,
>                                                   bdaddr_t *addr, u8 addr_type)
>
> base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db
> --
> 2.56.0

Sashiko flagged quite a few issues, please have a look and lets
resolve them before merging:
https://sashiko.dev/#/patchset/20261104120138.1165715-1-radek%40podgorny.cz

-- 
Luiz Augusto von Dentz