Channel field info for 6 GHz channels

Channel field info for 6 GHz channels

[Bill Stafford]

Sorry for the basic questions on this.
Has there been any discussion on 6 GHz channels representation in a RadioTap header?

The Channel field has a frequency field and I see flags for 5G and 2G.

Should a 6 GHz channel just be represented in the Channel field as the center frequency of the entire channel BW and neither bits set for 5G or 2G? (The frequency indicates that it is a 6G channel, so no need for a 6G bit I imagine.)

Does the channel bandwidth information get encoded in the radiotap header? Or it just supposed to be inferred from the cf? (I think one cf in 6G can only belong to one 20/40/80/160 MHz channel. 

I hope these are simple questions that might be answered off the cuff. If there is some code I should look to, please point me in the right direction.

Thanks in advance.

-Bill

Re: Channel field info for 6 GHz channels

[Johannes Berg]

Hi,

On Wed, 2019-07-03 at 14:27 -0700, Bill Stafford wrote:
> Sorry for the basic questions on this.
> Has there been any discussion on 6 GHz channels representation in a
> RadioTap header?

Not really.

> The Channel field has a frequency field and I see flags for 5G and 2G.

I've always sort of thought the flags are kinda useless, but I don't
know how those bits are really used, I guess you'd have to look at e.g.
wireshark. OTOH, we could say it's not relevant and tools that want to
handle 6 GHz will just have to not use the bits. I don't know. Or we can
add a bit for 6-7 GHz?

> Should a 6 GHz channel just be represented in the Channel field as the
> center frequency of the entire channel BW 

Note! I'm pretty sure that this field has always been used to represent
the *control channel* center frequency, so if you had a VHT 160 MHz
channel, it would've pointed to the primary 20 MHz channel's center
frequency. That we should probably keep.

> and neither bits set for 5G or 2G? (The frequency indicates that it is
> a 6G channel, so no need for a 6G bit I imagine.)

Neither bits makes sense, I guess.

> Does the channel bandwidth information get encoded in the radiotap
> header? Or it just supposed to be inferred from the cf? (I think one
> cf in 6G can only belong to one 20/40/80/160 MHz channel. 

The *bandwidth* usually gets encoded into the rate information. In the
6-7 GHz case you'd be using HE, so
http://www.radiotap.org/fields/HE

It's simpler for HT (http://www.radiotap.org/fields/MCS) where we just
have a couple of bits saying
	bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U

Now, oddly enough, it looks like we don't actually capture the
*position* of the 40 MHz channel at all.

If we need to capture more detailed channel position data (relative to
the primary channel whose center frequency is captured in the existing
channel field) I'd probably say we should have some new field that
captures this in more detail. In Linux, we capture the configuration in
something like

	u32 control_freq;
	enum ... bandwidth;
	u32 center_freq1;
	u32 center_freq2; // for 80+80

but we've already found that it's not sufficient for
 * S1G, which has channels with fractional MHz center frequency
 * EDMG, which has a bunch of non-contiguous chunks

johannes

Re: Channel field info for 6 GHz channels

[Bill Stafford]

[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]

Thanks for the information Johannes.

>> The Channel field has a frequency field and I see flags for 5G and 2G.
> 
> I've always sort of thought the flags are kinda useless, but I don't
> know how those bits are really used, I guess you'd have to look at e.g.
> wireshark.

I took a look at the current Wireshark code and see that the bits are being used to set the phy type of the rx frame.

Here are some excerpts from packet-ieee80211-radiotap.c, creating some masks including the radiotap channel flags for 2g/5g:
#define	IEEE80211_CHAN_DSSS \
	(IEEE80211_CHAN_2GHZ)
#define	IEEE80211_CHAN_A \
	(IEEE80211_CHAN_5GHZ | IEEE80211_CHAN_OFDM)
#define	IEEE80211_CHAN_B \
	(IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_CCK)

Then in dissect_radiotap_channel(), paraphrasing the switch on the channel flags:

	case IEEE80211_CHAN_DSSS:
		phdr->phy = PHDR_802_11_PHY_11_DSSS;
		break;

	case IEEE80211_CHAN_A:
		phdr->phy = PHDR_802_11_PHY_11A;
		phdr->phy_info.info_11a.has_turbo_type = TRUE;
		phdr->phy_info.info_11a.turbo_type = PHDR_802_11A_TURBO_TYPE_NORMAL;
		break;

	case IEEE80211_CHAN_B:
		phdr->phy = PHDR_802_11_PHY_11B;

The frequency could be used just as well, but I also see this comment in the same function:
	if (freq != 0) {
		/*
		 * XXX - some captures have 0, which is
		 * obviously bogus.
		 */
I don’t know if captures that have a zero freq bother setting 2g/5g bits.

> OTOH, we could say it's not relevant and tools that want to
> handle 6 GHz will just have to not use the bits. I don't know. Or we can
> add a bit for 6-7 GHz?

I don’t think a 6 GHz bit is necessary. Maybe if there is no 6G bit the drivers will be more inclined to fill out the frequency.

> Now, oddly enough, it looks like we don't actually capture the
> *position* of the 40 MHz channel at all.

Not really an issue I think other than 2 GHz band use. Since 5G and 6G bands have non-overlapping channels of any bandwidth, given a 20 MHz primary channel, you know the one and only 40/80/160 that contains that channel.
[btw, I am ignoring the legacy Japan channels 34,38,42,46, but they were never paired to 40MHz according to 802.11, but even if they were, given primary channel 34, you know that the 40MHz channel would be {34,38}, etc]

But 2 GHz 40MHz seems like it is left without knowing which of the 2 40MHz channels that contain a primary 20 MHz btwn 5-9.

> If we need to capture more detailed channel position data (relative to
> the primary channel whose center frequency is captured in the existing
> channel field) I'd probably say we should have some new field that
> captures this in more detail. In Linux, we capture the configuration in
> something like
> 
> 	u32 control_freq;
> 	enum ... bandwidth;
> 	u32 center_freq1;
> 	u32 center_freq2; // for 80+80
> 
> but we've already found that it's not sufficient for
> * S1G, which has channels with fractional MHz center frequency
> * EDMG, which has a bunch of non-contiguous chunks

I noticed that radiotap did not have any 80+80 encoding. I have not looked at S1G or EDMG, so can’t comment.
But it make sense to me to have some extended channel info in radiotap to encode these cases.  

Thanks again.

-Bill


[-- Attachment #2: Type: text/html, Size: 7628 bytes --]

Re: Channel field info for 6 GHz channels

[Johannes Berg]

Hi Bill,

> I took a look at the current Wireshark code and see that the bits are being used to set the phy type of the rx frame.
> 
> Here are some excerpts from packet-ieee80211-radiotap.c, creating some masks including the radiotap channel flags for 2g/5g:
> #define	IEEE80211_CHAN_DSSS \
> 	(IEEE80211_CHAN_2GHZ)
> #define	IEEE80211_CHAN_A \
> 	(IEEE80211_CHAN_5GHZ | IEEE80211_CHAN_OFDM)
> #define	IEEE80211_CHAN_B \
> 	(IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_CCK)
> 
> Then in dissect_radiotap_channel(), paraphrasing the switch on the channel flags:
> 
[...]

Interesting, ok.

> The frequency could be used just as well, but I also see this comment in the same function:
> 	if (freq != 0) {
> 		/*
> 		 * XXX - some captures have 0, which is
> 		 * obviously bogus.
> 		 */
> I don’t know if captures that have a zero freq bother setting 2g/5g bits.

That I don't know either, I haven't ever seen any such captures.

> > OTOH, we could say it's not relevant and tools that want to
> > handle 6 GHz will just have to not use the bits. I don't know. Or we can
> > add a bit for 6-7 GHz?
> 
> I don’t think a 6 GHz bit is necessary. Maybe if there is no 6G bit
> the drivers will be more inclined to fill out the frequency.

I think mostly they do. In Linux certainly we always have it, you can't
really *not* have it. I've never seen any captures from elsewhere that
don't have it either.

> > Now, oddly enough, it looks like we don't actually capture the
> > *position* of the 40 MHz channel at all.
> 
> Not really an issue I think other than 2 GHz band use. Since 5G and 6G
> bands have non-overlapping channels of any bandwidth, given a 20 MHz
> primary channel, you know the one and only 40/80/160 that contains
> that channel.

At least theoretically, yes. For monitor mode we might actually want to
be able to capture non-standard deployments.

It occurred to me later though that this is something you have to
actually *configure* on the sniffer to start with, i.e. you have to tell
it "please capture on channel 36 80+80 MHz with CF1==xyz, CF2==abc". So
you already must have that information, though recording it again in the
file could be useful since you might not _remember_ it.

Except in merged multi-device captures or simulation scenarios, where
you could possibly have a single capture file that contains more than
just a single channel, in simulation possibly *everything* that was
going on...

> But 2 GHz 40MHz seems like it is left without knowing which of the 2
> 40MHz channels that contain a primary 20 MHz btwn 5-9.

Right, only out-of-band from configuration again.

> > If we need to capture more detailed channel position data (relative to
> > the primary channel whose center frequency is captured in the existing
> > channel field) I'd probably say we should have some new field that
> > captures this in more detail. In Linux, we capture the configuration in
> > something like
> > 
> > 	u32 control_freq;
> > 	enum ... bandwidth;
> > 	u32 center_freq1;
> > 	u32 center_freq2; // for 80+80
> > 
> > but we've already found that it's not sufficient for
> > * S1G, which has channels with fractional MHz center frequency
> > * EDMG, which has a bunch of non-contiguous chunks
> 
> I noticed that radiotap did not have any 80+80 encoding. 

We didn't actually need it, because we only captured the *rate*, and
those are the same for 160 and 80+80. 80+80 also doesn't really seem to
be used much in practice, if ever?

Anyway, again, if we need/want to capture it we'll need to add a new
field that captures the channel configuration for that frame.

> But it make sense to me to have some extended channel info in radiotap
> to encode these cases.  

Agree. I don't have a real need for that right now so am unlikely to
work on a proposal, but if somebody did I'd be willing to support it
with Linux code.

johannes