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

[Ramasamy Kaliappan]

On 2/6/2026 2:35 PM, Benjamin Berg wrote:
> On Thu, 2026-02-05 at 22:34 +0530, Ramasamy Kaliappan wrote:
>> 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.
> 
> I am not sure we really need to care about this case, but, I think we
> can handle it just fine if we want to.
> 
> In this case is mac80211 would translate the address to the MLD Address
> and would not include the NO_STA flag. hostapd can look up the MLD
> Address in its database and translate the address back to the link
> address for its internal use. It can also explicitly TX the response to
> the link address by setting the NO_STA flag.
> 
> So, I think it is an interesting corner case and we need to make sure
> to not get confused by it. But, hostapd should be able to handle it.
> Either by simply rejecting the AUTH or by making sure the MLD addresses
> are all correct if the association succeeds.
> 
> Btw. I did start looking into doing the mac80211/cfg80211 changes. How
> should we do it with hostapd? Is someone on your side maybe able to
> work on the hostapd part?
> 
Sure, we will work on the hostapd side once you post the 
mac80211/cfg80211 changes.

The below few test scenarios we have observed with various IoT client 
behaviors. These are cases hostapd/mac80211 must correctly interpret the 
frame origin and address mappings.

These scenarios involve address reuse, link address swapping, and mixed 
MLD/legacy reconnection patterns seen during roaming or second 
connection request:

1. AP MLD with 3 links (wlan0): a legacy (non‑MLD) station initially 
connects on 5 GHz and later roams back legacy station to the 6 GHz link 
of the same AP MLD.
2. AP MLD with 3 links: a SLO station initially connects to 5 GHz using 
link address L1 and MLD address M1, then attempts to reconnect on the 
same 5 GHz link using only the MLD address M1.
Incoming probe/auth/assoc frames use the MLD address → link/MLD address 
swapping occurs.
3. MLD AP with 3 links: SLO STA is initially connected on 5 GHz (L1, 
M1). Second connection same station attempts to connect on 6 GHz using 
L1 address(5GHz link address).  it sends probe/auth/assoc frames on 
6 GHz using the 5 GHz link address L1 with the same MLD address M1.
4. MLD AP with 3 links: Initial SLO station connected (L1, M1 on 5 GHz). 
Second connection same station attempts to connect on 6 GHz using the 
MLD address M1.
5. MLD AP with 3 links: an MLD STA is connected on 5 GHz + 6 GHz. A 
legacy STA later attempts to reconnect using the same MLD address on 
5 /6 GHz.
6. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
another 2‑link MLD STA using (L1, L2, M1).
7. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
another STA using (L2, L1, M) (links swapped).
8. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
STA uses (L1, M, L2).
9. Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
STA uses (M, L2, L1).
10.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
STA uses (L1, M, M1).
11.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
STA uses (M, L2, M1).
12.Initial connection: 2‑link MLD STA (L1, L2, M). Second connection: 
STA uses (M, A, M1) (A = a new link address).

We need to clarify how NL80211_ATTR_FRAME_NO_STA will be handled in each 
of these cases.

@Jouni- These corner‑case behaviors were observed with some of IOT 
clients. Handling this attribute within hostapd introduces some 
additional logic to find appropriate sta, source address for received 
frames and destination address to response.

Please share your thoughts on this approach?

> Benjamin