Re: [RFC PATCH v2 0/8] Adding NO_STA flag and reworking RX link resolution

[Benjamin Berg <benjamin@sipsolutions.net>]

Hi,

On Mon, 2026-04-27 at 15:32 +0530, Ramasamy Kaliappan wrote:
> [SNIP]
> The hostapd changes were made and validated against the relevant test
> cases. During testing, we observed some complexities in specific 
> scenarios particularly when a Non‑AP STA first associates as L1 (M1)
> and then reappears as L1 (M2) during the authentication/association phase.
> In this case, on the RX path, when an authentication frame for L1 (M2 in 
> the ML IE) is received, the driver finds the existing STA L1 (M1) and
> therefore does not add the NO_STA attribute.

Yes, the address will be translated in that case.

> As a result, the complexity of handling authentication and association 
> frames increases within the user‑space hostapd application. While 
> processing the authentication frame, hostapd parses the ML IE
> but fails to create a new STA entry for L1 (M2) in the driver, 
> especially in scenarios involving different MLD addresses.
> 
> To simplify this handling, we would like to explore an alternative 
> approach that avoids address translation for management frames 
> (authentication, association, and reassociation),
> regardless of whether the STA already exists.

I am not sure why that would be easier. Also, my hunch is that it makes
sense to translate the address in particular with encrypted association
frames.

hostapd receives the link ID that the frame was received on. So when
the address was translated (no NO_STA flag), hostapd can use the MLD
Address + Link ID to do a lookup in its own station database and use
that to look up the SA address that was used to TX the frame. So you
should be able to emulate the suggested mac80211 behaviour inside
hostapd.

Note that when a STA that first used L1 (M1) reappears using L1 (M2),
then hostapd cannot create a STA entry in mac80211. So the existing M1
address should be used to TX the SA Query to the old station, while an
explicit TX to L1 with the NO_STA flag needs to be done for the
comeback frame.

I believe that hostapd will need a bit of refactoring, including
improved tracking to know whether a STA has been inserted into the
driver and whether to TX the AUTH frames using the link address and
NO_STA flag or using the MLD Address.

> However, this approach may introduce backward compatibility concerns 
> when either the driver or hostapd is not updated.
> To address this, we propose introducing a capability indication 
> mechanism between the driver and user space (driver ↔ hostapd).
> Based on the advertised capabilities, mac80211 can then skip 
> management‑frame address translation accordingly.
> 
> Benjamin and Jouni, Could you please help share your thoughts on this?

Right, I would like to avoid introducing a new capability mechanism
unless it is a real improvement for the hostapd implementation. It
could well be that I am missing something, but right now I do not see
that this is the case.

If you are still unsure, then I guess we should probably go back to the
list of scenarios we had and check for each one how it can be detected
and how it should be handled.

Benjamin