Re: [PATCH RFC wireless-next] wifi: mac80211: correct rx freq handling for S1G

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2026-10-02 at 17:29 +1000, Lachlan Hodges wrote:
> 6d531b9af16e ("wifi: mac80211: rework RX packet handling") reworked
> Rx frame handling with a specific focus on MLD, but it also introduced
> some changes for non-MLD interfaces. Previously when a station was
> looked up (either because the driver did not pass one or handling
> a management frame) it was done via hdr->addr2 and that was it. Now
> the received frames frequency is validated against the links
> control channel alongside the station lookup.

No surprise, I guess, but sorry.

> S1G has a unique feature where the control or primary channel can
> either be 1MHz or 2MHz. However there is _always_ a 1MHz primary.
> S1G drivers advertise these 1MHz primaries but it means if a 2MHz
> primary is used the control channel inside the chandef may not be
> the channel used to pass management frames.

Yeah, so I think part of this is also related to how we through the 1
MHz vs. 2 MHz in S1G. I feel like the spec thinks this differently,
while in the chandef we basically think it almost as if 2 MHz was
equivalent to 40 MHz HT, combined out of two 1 MHz channels, except we
added the flag:

 * @s1g_primary_2mhz: Indicates if the control channel pointed to
 *      by 'chan' exists as a 1MHz primary subchannel within an
 *      S1G 2MHz primary channel.

To also answer your question first:

> is rx_status->freq always meant to be the control channel? 

For HT/..., yes, that's how it works. Not sure that's really *by design*
as much as by historical accident, but I don't think we will (even can)
change it now.

In some way it makes sense though because otherwise you'd see this
flicker around all the time as frames with different bandwidths are
transmitted, which would be strange too in a single BSS.

Note it also affects how radiotap is reported, so S1G might be in the
opposite camp now, wanting to report the 2 MHz channel center frequency?

>    For
>    management frames obviously makes sense but for data frames
>    sent on a wider channel wouldn't this be set to the operating
>    channel? Especially for i.e sniffer? The mm81x driver reports
>    it like this but maybe it should just report the control channel?

So .. are you saying you always report the _overall_ center frequency,
even for 4/8/16 MHz widths, or just for 1 MHz vs 2 MHz primary?

I note that even S1G radiotap didn't really specify where the channel
is: https://radiotap.org/fields/S1G, so I'm not sure it can even report
everything correctly? The "Channel" field can't even cover the 1/2 MHz
centers.

So I think in some way this is almost more of a question of what you
want/need for radiotap than anything else.

Internally, reporting just the (1 MHz) "chandef primary" would be
matching the HT/... behaviour.

> As a result, the rework
> causes the following two issues on an S1G link:
> 
> 1. When data frames are passed to mac80211 without a station (for
>    example using ieee80211_rx_ni()) the frames rx status frequency
>    is compared against the 1MHz control frequency used by the link
>    via ieee80211_rx_valid_freq. Since the rx status reported is of
>    the center frequency of transmission (i.e either the operating
>    channel or the 2MHz primary in the case of multicast/EAPOL etc.)
>    these frames are _all_ dropped.

Of course if you're using rx_ni() now then you could possibly arrange to
call ieee80211_rx_napi(hw, link_sta, skb, NULL) with the correct station
looked up beforehand, and entirely bypass the question, doing whatever
you want with the frequency?

johannes