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

[Luiz Augusto von Dentz]

Hi Radek,

On Tue, Sep 8, 2026 at 4:41 PM Radek Podgorny <radek@xxxxxxxxxxx> wrote:
>
> 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.

That probably worth fixing, but yes it can be done on top.

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

But if it advertises using the identity, we should connect using the
identity as well; there's no reason to use the stale RPA if the peer
somehow disabled its privacy.

> v2 follows as a single patch.
>
> Radek



-- 
Luiz Augusto von Dentz