[PATCH v2 2/3] AP: Always re-add stations that use MLO

[Benjamin Berg]

Hi,

On Thu, 2026-01-29 at 22:56 +0530, Rameshkumar Sundaram wrote:
> On 1/29/2026 3:38 PM, Benjamin Berg wrote:
> > [SNIP]
> > That said, to properly fix this we need an nl80211/mac80211 API that
> > permits us to disable address translation for the frame. Otherwise we
> > would still get the address translated to the old link address should
> > the new link address match the MLD address.
> > 
> 
> That's true—even probe responses get translated when the old link 
> address matches the new link MLD address.
> 
> Few other cases I encountered:
> Consider an ML STA with ML address M associated with link A and link B, 
> using link addresses X and Y respectively. If the STA sends an 
> authentication frame with address Y on link A, it gets translated to M 
> (even though link A has no STA with address Y) and forwarded to link B. 
> As a result, hostapd is unaware of the actual TA and queues the 
> authentication reply to the MLD address on link B. This frame will 
> eventually be transmitted over the air on link B with address Y.

Honestly, that type of link confusion seems like a bug. We should be
able to avoid that as we hopefully know on which link the frame was
received.

> This will be true even if STA associated in one link and tries to roam 
> to other link of MLD using same link and ML addresses.
> 
> There also cases where an ML STA roams/re-associates as legacy (non-ML) 
> STA with ML address as link address. The reply would go out with old 
> link address.

Yes, I think that case is similar a station using its MLD Address on
the association link and returning on another link.

> It seems that address translation at the driver/mac80211 level for 
> management frames could be avoided for both TX and RX, allowing hostapd 
> to handle these frames and their replies more efficiently in cases of
> roaming and address reuse.

Doing address translation in the TX path is required if the
hardware/driver should decide on which link to TX the frame. For RX, it
seems sensible to me to do the translation when it is possible.

I talked a bit to Johannes about this today, and my current proposal
would be add a new flag that is set when mac80211 did not find (RX) or
should not use (TX) a STA for the frame.

More specifically I think that we could:
 * Fix the link address based STA lookup to only work when the frame
   was received on the correct link (the bug from above).
 * Make sure we drop robust management frames without a STA as we do
   not want to get into trouble with the next change.
 * Change ieee80211_rx_for_interface so that it uses only
   link_sta_info_get_bss if we are an MLD and sta_info_get_bss
   otherwise.
   Right now, we will find the station if we see the MLD Address in the
   frame even when it is not a valid link address.
 * Add a new nl80211 attribute NL80211_ATTR_FRAME_NO_STA to be used
   together with NL80211_CMD_FRAME for both TX and RX.
    - In the RX case, add the attribute if we have no station. If the
      attribute does not exist, then hostapd should assume the address was
      translated.
    - In the TX case, plumb the information through to mac80211 and avoid
      doing a station lookup based on the address.

I think this would be enough to then solve the problem in hostapd.

Benjamin