Re: Channel field info for 6 GHz channels

[Bill Stafford <bill.stafford-BUHhN+a2lJ4@public.gmane.org>]

[-- 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 --]