RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Bill Stafford <bill.stafford-BUHhN+a2lJ4@public.gmane.org>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org
Subject: Re: Channel field info for 6 GHz channels
Date: Sun, 14 Jul 2019 14:10:29 -0700
Message-ID: <3A61B59B-0D87-46AF-8943-5EF5A1207DFB@me.com> (raw)
In-Reply-To: <8e6970d56da3998227aef4df44c7430c9c41822c.camel-cdvu00un1VgdHxzADdlk8Q@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 --]

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for the information Johannes.<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">The Channel field has a frequency field and I see flags for 5G and 2G.<br class=""></blockquote><br class="">I've always sort of thought the flags are kinda useless, but I don't<br class="">know how those bits are really used, I guess you'd have to look at e.g.<br class="">wireshark.</div></div></blockquote><div><br class=""></div><div><div class="">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.</div><div class=""><br class=""></div><div class="">Here are some excerpts from packet-ieee80211-radiotap.c, creating some masks including the radiotap channel flags for 2g/5g:</div><div class=""><div class=""><font face="Courier New" class="">#define<span class="Apple-tab-span" style="white-space: pre;">	</span>IEEE80211_CHAN_DSSS \</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>(IEEE80211_CHAN_2GHZ)</font></div><div class=""><font face="Courier New" class="">#define<span class="Apple-tab-span" style="white-space:pre">	</span>IEEE80211_CHAN_A \</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>(IEEE80211_CHAN_5GHZ | IEEE80211_CHAN_OFDM)</font></div><div class=""><font face="Courier New" class="">#define<span class="Apple-tab-span" style="white-space:pre">	</span>IEEE80211_CHAN_B \</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>(IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_CCK)</font></div><div class=""><br class=""></div></div><div class="">Then in dissect_radiotap_channel(), paraphrasing the switch on the channel flags:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>case IEEE80211_CHAN_DSSS:</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>phdr-&gt;phy = PHDR_802_11_PHY_11_DSSS;</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>break;</font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>case IEEE80211_CHAN_A:</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>phdr-&gt;phy = PHDR_802_11_PHY_11A;</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>phdr-&gt;phy_info.info_11a.has_turbo_type = TRUE;</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>phdr-&gt;phy_info.info_11a.turbo_type = PHDR_802_11A_TURBO_TYPE_NORMAL;</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>break;</font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>case IEEE80211_CHAN_B:</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>phdr-&gt;phy = PHDR_802_11_PHY_11B;</font></div></div><div class=""><br class=""></div></div><div>The frequency could be used just as well, but I also see this comment in the same function:</div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">	</span>if (freq != 0) {</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span>/*</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span> * XXX - some captures have 0, which is</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span> * obviously bogus.</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre">		</span> */</font></div><div class="">I don’t know if captures that have a zero freq bother setting 2g/5g bits.</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class=""> OTOH, we could say it's not relevant and tools that want to<br class="">handle 6 GHz will just have to not use the bits. I don't know. Or we can<br class="">add a bit for 6-7 GHz?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Now, oddly enough, it looks like we don't actually capture the<br class="">*position* of the 40 MHz channel at all.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><div>[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]</div><div class=""><br class=""></div></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">If we need to capture more detailed channel position data (relative to<br class="">the primary channel whose center frequency is captured in the existing<br class="">channel field) I'd probably say we should have some new field that<br class="">captures this in more detail. In Linux, we capture the configuration in<br class="">something like<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">	</span>u32 control_freq;<br class=""><span class="Apple-tab-span" style="white-space:pre">	</span>enum ... bandwidth;<br class=""><span class="Apple-tab-span" style="white-space:pre">	</span>u32 center_freq1;<br class=""><span class="Apple-tab-span" style="white-space:pre">	</span>u32 center_freq2; // for 80+80<br class=""><br class="">but we've already found that it's not sufficient for<br class=""> * S1G, which has channels with fractional MHz center frequency<br class=""> * EDMG, which has a bunch of non-contiguous chunks<br class=""></div></div></blockquote></div><br class=""></div><div class="">I noticed that radiotap did not have any 80+80 encoding. I have not looked at S1G or EDMG, so can’t comment.</div><div class="">But it make sense to me to have some extended channel info in radiotap to encode these cases. &nbsp;</div><div class=""><br class=""></div><div class="">Thanks again.</div><div class=""><br class=""></div><div class="">-Bill</div><div class=""><br class=""></div></body></html>

  parent reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03 21:27 Bill Stafford
     [not found] ` <1F1CB1A0-193E-4591-AD86-ECEA34B97030-BUHhN+a2lJ4@public.gmane.org>
2019-07-12  7:09   ` Johannes Berg
     [not found]     ` <8e6970d56da3998227aef4df44c7430c9c41822c.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-07-14 21:10       ` Bill Stafford [this message]
     [not found]         ` <3A61B59B-0D87-46AF-8943-5EF5A1207DFB-BUHhN+a2lJ4@public.gmane.org>
2019-07-15  7:06           ` Johannes Berg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A61B59B-0D87-46AF-8943-5EF5A1207DFB@me.com \
    --to=bill.stafford-buhhn+a2lj4@public.gmane.org \
    --cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
    --cc=radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git