From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Stafford 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> References: <1F1CB1A0-193E-4591-AD86-ECEA34B97030@me.com> <8e6970d56da3998227aef4df44c7430c9c41822c.camel@sipsolutions.net> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5F9D5D11-6526-4C58-9453-A77DBB4B24C9" Return-path: In-Reply-To: <8e6970d56da3998227aef4df44c7430c9c41822c.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org List-Unsubscribe: To: Johannes Berg Cc: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org List-Id: radiotap@radiotap.org --Apple-Mail=_5F9D5D11-6526-4C58-9453-A77DBB4B24C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the information Johannes. >> The Channel field has a frequency field and I see flags for 5G and = 2G. >=20 > 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 =3D PHDR_802_11_PHY_11_DSSS; break; case IEEE80211_CHAN_A: phdr->phy =3D PHDR_802_11_PHY_11A; phdr->phy_info.info_11a.has_turbo_type =3D TRUE; phdr->phy_info.info_11a.turbo_type =3D = PHDR_802_11A_TURBO_TYPE_NORMAL; break; case IEEE80211_CHAN_B: phdr->phy =3D 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 !=3D 0) { /* * XXX - some captures have 0, which is * obviously bogus. */ I don=E2=80=99t 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=E2=80=99t 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 >=20 > u32 control_freq; > enum ... bandwidth; > u32 center_freq1; > u32 center_freq2; // for 80+80 >=20 > 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=E2=80=99t comment. But it make sense to me to have some extended channel info in radiotap = to encode these cases. =20 Thanks again. -Bill --Apple-Mail=_5F9D5D11-6526-4C58-9453-A77DBB4B24C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =3D = PHDR_802_11_PHY_11_DSSS;
= break;

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

= case IEEE80211_CHAN_B:
phdr->phy =3D = 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 !=3D 0) = {
= /*
= * XXX - some captures have 0, which is
* obviously = bogus.
= */
I don=E2=80=99t 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=E2=80=99t 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=E2=80=99t = comment.
But it make sense to me to have some = extended channel info in radiotap to encode these cases. =  

Thanks = again.

-Bill

= --Apple-Mail=_5F9D5D11-6526-4C58-9453-A77DBB4B24C9--