Re: [PATCH wireless-next] wifi: radiotap: add definitions for the new UHR TLVs

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2026-04-15 at 15:27 +0200, Pablo MARTIN-GOMEZ wrote:
> 
> > +	IEEE80211_RADIOTAP_UHR_ELR = 37,
> > +	IEEE80211_RADIOTAP_UHR = 38,
> Why are the values 37 and 38 but below in the doc 35 and 38?

The doc doesn't even exist yet as you say? Other things are being
assigned to 35/36.

> > +/*
> > + * ieee80211_radiotap_uhr_elr - content of UHR-ELR TLV (type 35)
> > + * see https://www.radiotap.org/fields/UHR-ELR for details
> The URL gives a error 404

Yeah it's not merged yet. For now you can see the (draft) at
https://jmberg.github.io/radiotap.github.io/fields/UHR-ELR (etc)

> > +enum ieee80211_radiotap_uhr_known {
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_SPATIAL_REUSE		= 0x00000001,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_GI_LTF_SIZE		= 0x00000002,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_NUMBER_OF_UHR_LTF_SYMBOLS	= 0x00000004,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_LDPC_EXTRA_SYMBOL_SEGMENT	= 0x00000008,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_PRE_FEC_PADDING_FACTOR	= 0x00000010,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_PE_DISAMBIGUITY		= 0x00000020,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_DISREGARD_OFDMA		= 0x00000040,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_CRC1			= 0x00000080,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_TAIL1			= 0x00000100,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_CRC2			= 0x00000200,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_TAIL2			= 0x00000400,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_INTERFERENCE_MITIGATION	= 0x00000800,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_DISREGARD_NON_OFDMA	= 0x00001000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_NUMBER_OF_NON_OFDMA_USERS	= 0x00002000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_COMMON_ENCODING_BLOCK_CRC	= 0x00004000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_COMMON_ENCODING_BLOCK_TAIL	= 0x00008000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_RU_MRU_DRU_SIZE		= 0x00010000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_RU_MRU_INDEX		= 0x00020000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_DRU_RRU_ALLOC_TB_FMT	= 0x00040000,
> > +	IEEE80211_RADIOTAP_UHR_KNOWN_PRI80_CHAN_POS		= 0x00080000,
> > +};
> In the other radiotap fields, the `known` fields are (as far as I
> checked) have the same order than the data, but here, for example,
> `PRI80_CHAN_POS` is before `INTERFERENCE_MITIGATION  ` in `known` but
> after in `data`. Any reason for that?

Any reason you care? ;-) I think I just assigned them in the order I
needed them, and in this case you really should look at the radiotap
spec for it too. Some of it may also be due to having copied some things
from EHT and then filling gaps with new bits, perhaps. Since other
people are already working on wireshark support etc. I don't think we'll
be changing this without a good reason.

johannes