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

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2026-10-02 at 19:54 +1000, Lachlan Hodges wrote:
> > 
> > >    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?
> 
> Yes, our firmware reports the frame at the overall center frequency,
> even for 4/8/16 MHz widths. Looking at our out of tree shim driver
> (5G mapping) it does the same thing i.e report the center frequency
> of 40/80/160 channel which is probably why mm81x does this.

I guess that makes some sense.

> Anyways this is not really a big deal knowing that we can just
> override it with the 1MHz control channel.

Sure, but should you?

> > 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.
> 
> Yea this is on the TODO list.. Once initial monitor mode support lands,
> which I was going to send today but this bug has appeared, then we'll
> be fixing up the radiotap standard to better convey everything.

:)

> > So I think in some way this is almost more of a question of what you
> > want/need for radiotap than anything else.
> 
> So another question then, Im looking at a poorly sourced 802.11ac
> wireshark capture and in the radiotap header it has:
> 
> 802.11 radio information
>     PHY type: 802.11ac (VHT) (8)
>     Short GI: False
>     Bandwidth: 80 MHz (4)
>     TXOP_PS_NOT_ALLOWED: False
>     User 0: MCS 7
>     Data rate: 292.5 Mb/s
>     Channel: 36
>     Frequency: 5180MHz
>     Signal strength (dBm): -40 dBm
>     Noise level (dBm): -96 dBm
>     Signal/noise ratio (dB): 56 dB
>     TSF timestamp: 1911262072856970
>     [Duration: 53µs]
> 
> Where this is just a QoS data frame.. channel 36 is a 20MHz control
> channel @ 5180MHz and a width of 80MHz. I am assuming then, that if
> we were to follow this (as mentioned above) in the radiotap portion
> it would show as the 1MHz control (for channel + freq) and the width
> being the operating 4/8/.. ?

I don't know - I believe that "802.11 radio information" is synthesised
by wireshark from the other fields. It'd have to actually implement that
first, presumably by parsing some S1G data.

But once that's there I guess yes, that's what it'd show. You could also
just have it synthesise it differently I guess, or take only things from
some (extended) S1G field, or ... any number of things?

> Anyways, it seems like a small patch to handle freq_offset and then
> just changing the driver to report the 1MHz primary should hopefully
> fix all this up so Ill send that once I confirm.

If that's OK then I guess might be simplest overall.

johannes