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

[Rameshkumar Sundaram]

On 1/29/2026 3:38 PM, Benjamin Berg wrote:
> On Wed, 2026-01-28 at 10:58 +0530, Rameshkumar Sundaram wrote:
>>> [SNIP]
>>>    	if (FULL_AP_CLIENT_STATE_SUPP(hapd->iface->drv_flags) &&
>>> -	    (!(sta->flags & WLAN_STA_MFP) || !ap_sta_is_authorized(sta)) &&
>>> +	    (!(sta->flags & WLAN_STA_MFP) || !ap_sta_is_authorized(sta) ||
>>> +	     mld_sta) &&
>>
>> Doing this will reset the connection (and keys) of the existing
>> authorized ML STA in the driver. A simple authentication frame received
>> with the MLD address set to the existing authorized STA’s address could
>> terminate the secured association.
> 
> Uh, yes, what an embarrassing mistake …
> 
>> Should we instead defer this until the association request is received,
>> where SA‑Query validation can be performed? Or perhaps until the SAE
>> exchange is completed, if the authentication algorithm is SAE?
> 
> Yes, generally we should wait for SA-Query before kicking/modifying the
> station. I checked internally, and in particular for 11bi, we should do
> that once the authentication is completed without doing an SA-Query in
> that case.
> 
> That said, I believe we do have a problem until that point as we
> currently send the frames to the MLD address and rely on address
> translation which will use the old link address. At least in this case,
> we will need to send the frames directly to the new link address
> instead.
> 
> 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.

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.

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.


--
Ramesh