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

[Benjamin Berg]

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?

Benjamin