RadioTap Archive on
 help / color / Atom feed
From: Johannes Berg <>
To: Bill Stafford <>
Subject: Re: Channel field info for 6 GHz channels
Date: Mon, 15 Jul 2019 09:06:08 +0200
Message-ID: <> (raw)
In-Reply-To: <>

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.


      parent reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03 21:27 Bill Stafford
     [not found] ` <>
2019-07-12  7:09   ` Johannes Berg
     [not found]     ` <>
2019-07-14 21:10       ` Bill Stafford
     [not found]         ` <>
2019-07-15  7:06           ` Johannes Berg [this message]

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:

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

  git send-email \ \ \ \ \

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

RadioTap Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone