Re: [PATCH 2/2] Bluetooth: put the peer's on-air address on air when we cannot resolve

[Radek Podgorny]

Hi Luiz,

On Tue, Sep 8, 2026 at 4:00 PM Luiz Augusto von Dentz wrote:

> Ok, the problem is then that we are trying to an indentity address to
> connect when LL Privacy is not supported, so we probably can just
> revert to use the private address at hci_conn_add in LL Pirvacy is not
> supported or we didn't program the address in the resolving list.

Agreed, that is the better place. v2 does exactly that: __hci_conn_add()
keeps the RPA that hci_connect_le() swapped in unless
HCI_LL_RPA_RESOLUTION is set and the peer's identity is actually in
le_resolv_list. All of the hci_sync.c changes are gone;
le_conn_complete_evt() already resolves conn->dst back to the identity
once the link is up, so the round trip comes for free.

One cost worth naming: with the RPA in conn->dst from creation,
hci_conn_params_lookup() in hci_le_create_conn_sync() misses the
identity-keyed conn params and the connection falls back to the default
intervals. That is the pre-14b06c3a88f7 behaviour, so nothing regresses
relative to the code this fixes; if it matters it can be done on top by
resolving through hci_get_irk() the way hci_connect_le_scan_cleanup()
already does.

> Not really following why this is needed though, we always scan before
> connecting, so perhaps we need to update the rpa whenever we resolve
> at process_adv_report:
>
> /* Check if we need to convert to identity address */
> irk = hci_get_irk(hdev, bdaddr, bdaddr_type);
> if (irk) {
> bdaddr = &irk->bdaddr;
> bdaddr_type = irk->addr_type;
> }
>
> So we do translate the advertisements to back to the identity address,
> but we don't update the irk->rpa, which is probably what shall be used
> in case the controller cannot resolve.

irk->rpa is already kept current on that path, one call deeper than the
snippet: hci_get_irk() routes any RPA to hci_find_irk_by_rpa(), whose
second loop does

	if (smp_irk_matches(hdev, irk->val, rpa)) {
		bacpy(&irk->rpa, rpa);

so every advertising report the host resolves refreshes the cached RPA,
including across a rotation. That is what the old swap in
hci_connect_le() fed on, and it still runs today.

Which also answers the timestamp question. Since every
scan-then-connect path refreshes irk->rpa from the report that triggered
the connect, the freshness check only matters for a peer that
distributed an IRK, used RPAs, and later went back to advertising its
identity address - the cached RPA then stays stale forever and keeps
being dialled. That corner predates 14b06c3a88f7 and has shipped that
way for years, so I have dropped the rpa_jiffies patch entirely; it can
come back as a separate change if that corner is ever worth closing.

v2 follows as a single patch.

Radek