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

[Ramasamy Kaliappan]

Hi,

On 1/30/2026 5:32 PM, Benjamin Berg wrote:
> 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.
> 

I feel this approach should work. I'm trying to understand how it 
behaves in the following scenario where the STA reconnects with the same 
link address but a new(different) MLD address.

Consider a situation where an already associated STA sends a reconnect 
request using the same link addresses but a different MLD address.

For example, assume the station was originally connected using M as the 
MLD address, with L1 and L2 as its link addresses. When the STA 
reconnects (or roam back), it may use a new MLD address B while still
using the same link addresses L1 and L2.

In such a case, mac80211 will still find the existing STA entry based on 
the link address, and address translation would map the link address to 
the old mld address. Since the STA lookup succeeds, 
NL80211_ATTR_FRAME_NO_STA would be set to 0.

How is this expected to be handled in hostapd? I believe hostapd will 
also need additional logic to correctly handle this case, since the
link address maps to an already‑known STA, but the MLD address has changed.
Otherwise, hostapd may end up replying to the old MLD address or 
associating the frame with the wrong MLD context.

> Benjamin
> 

Thanks,
Ramasamy