public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Remi Pommarel <repk@triplefau.lt>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless-next 0/3] Allow non-MLD sta to roam between MLD AP links
Date: Thu, 10 Jul 2025 15:21:08 +0200	[thread overview]
Message-ID: <aG--RKqY7RBfkvLR@pilgrim> (raw)
In-Reply-To: <4d50e8de5750cd6b915f209b9d3ab26f34efda99.camel@sipsolutions.net>

On Tue, Jul 08, 2025 at 11:00:26AM +0200, Johannes Berg wrote:
> On Fri, 2025-06-27 at 22:46 +0200, Remi Pommarel wrote:
> > 
> > To fix that, the first patch of this serie does not report management
> > frames with a link id (link id == -1) and let hostapd do the freq to
> > link conversion to respond. This relies on the fact that hostapd knows
> > how to do this freq to link conversion which is needed anyway for the
> > first pre-association scan. We can also do this conversion in mac80211
> > instead if it is deem preferrable.
> 
> You should probably send patches as RFC if you have things like that.

Sure. Some subsystems have a tendency to ignore those RFCs patches but
that does not seem to be the case for linux-wireless.

> 
> > This serie along with the mentionned hostapd patch allowes a non-MLD
> > STA to successfully roam between several MLD AP links with hwsim.
> 
> Maybe so, but does anything _else_ MLO related still work? Surely it
> cannot, given you just unconditionally made it no longer have a link ID
> ... And indeed most of the EHT hwsim tests no longer pass, and even
> crash the kernel.
> 
> Since you clearly were running hwsim tests, please run the existing ones
> too :)

Agh, sorry about that. I was not running the hostapd's hwsim tests
because I just discovered they exist. With the mentionned hostapd
patch most of them pass, but yes of course, let's not break old
wpa_supplicant/hostapd with kernel changes.

Doing freq to link id conversion instead makes all eht test to pass (I
will of course also add a hwsim test for this specific issue).

> 
> Also, I suspect that https://lore.kernel.org/linux-
> wireless/20250630084119.3583593-1-quic_sarishar@quicinc.com/ might go
> some way towards fixing this as well?

No I am afraid this one won't help.

The issue here is receiving off channel management frames and using the
link id the sta is currently associated with to report them to userland.
For example if sta is associated with link 0 and send a probe request on
link 1 (off channel scan), this frame should be reported to hostapd with
either no link id or a link id of 1.

Thanks

-- 
Remi

      reply	other threads:[~2025-07-10 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-27 20:46 [PATCH wireless-next 0/3] Allow non-MLD sta to roam between MLD AP links Remi Pommarel
2025-06-27 20:46 ` [PATCH wireless-next 1/3] wifi: mac80211: Do not set link_id for received management frame Remi Pommarel
2025-06-27 20:46 ` [PATCH wireless-next 2/3] wifi: mac80211: Check link id at station removal Remi Pommarel
2025-06-27 20:46 ` [PATCH wireless-next 3/3] wifi: mac80211: Correctly init MLO link in ieee80211_8023_xmit() Remi Pommarel
2025-07-08  9:00 ` [PATCH wireless-next 0/3] Allow non-MLD sta to roam between MLD AP links Johannes Berg
2025-07-10 13:21   ` Remi Pommarel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aG--RKqY7RBfkvLR@pilgrim \
    --to=repk@triplefau.lt \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox