From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>,
"radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org"
<radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org>
Cc: Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>,
Richard Sharpe
<realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: Correct radiotap header for 802.11ad
Date: Thu, 17 Sep 2015 18:37:59 +0200 [thread overview]
Message-ID: <1442507879.2821.9.camel@sipsolutions.net> (raw)
In-Reply-To: <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
On Thu, 2015-09-10 at 11:25 -0700, Guy Harris wrote:
>
> The ones that aren't in the MCS field or the A-MPDU field are:
>
> HT Length - is that just the length of the data following
> the radiotap header?
I don't think so - at least not with A-MPDU.
> Smoothing
>
> Not Sounding
>
> CRC - is this of any interest?
>
> Tail Bits - always 0, so these are presumably not of
> interest
>
> Can:
>
> whether "20" means "20", "20L", or "20U";
>
> HT mixed vs. greenfield;
>
> both of which are available from the MCS field, be determined from
> the PLCP header?
>
> Or is what "20" means not fully determinable for received packets, so
> that "20L", "20U", and "40" are indistinguishable, similar to what
> the Radiotap spec for the VHT field says?
I have a hard time seeing 20L/20U being distinguishable if you're
hearing those while tuned to a 20 MHz channel, but if you're tuned to a
40 MHz channel then perhaps that's possible - likely not from the PLCP
though since that would have to look like a regular 20 MHz transmission
for purposes of somebody picking it up on a 20 MHz channel? I'm not
really all that familiar with the PHY details though.
> 20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format
> of the HT-SIG of an HT-greenfield format frame is identical to the HT
> -SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if
> that information can be determined for received frames, it sounds as
> if greenfield vs. mixed *can't* be determined from the HT-SIG bits.
You can know whether or not it was preceded by a compat preamble
though.
> For *transmitted* frames, I guess you have more control over how it's
> transmitted, which is presumably why there's a VHT field rather than
> just a PLCP header field.
>
> I.e., as radiotap is used for transmission, it needs to include at
> least some of the parameters to the PHY service's transmission
> operation, which may not be available in the PLCP header.
That's also a good point - having to build a PLCP signal field for
transmission would be somewhat painful, especially if you just want to
control some part of the transmission.
> And is there anything more that would be needed for *injected* 11ad
> frames? If so, that's an argument for a "DMG" field containing the
> interesting information from the PLCP header combined with
> information necessary for injected frames?
Not being familiar with DMG, I can't really comment on this.
It does sound like we need *some* new field though, be it either a DMG
field or a PLCP SIGNAL field, or perhaps even both.
Going back to the original thread though, I think using the MCS field
is quite wrong.
johannes
next prev parent reply other threads:[~2015-09-17 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-22 19:41 Correct radiotap header for 802.11ad Richard Sharpe
[not found] ` <CACyXjPzq-ePB1ux6wi_Rv3onPKXomcJcm15XJwA51u0E4W2txw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 20:59 ` Guy Harris
[not found] ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-22 22:06 ` Richard Sharpe
[not found] ` <CACyXjPx81fh_jeQSUjE-_w8NQ_Jr-ajmnVWSopfzcLPOWoGmGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 22:24 ` Guy Harris
2015-08-22 23:34 ` Guy Harris
[not found] ` <1606812C-649C-4C06-ABE0-AE2F4474BCD0-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-24 7:40 ` Johannes Berg
[not found] ` <1440402013.3735.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-08-24 16:21 ` Richard Sharpe
[not found] ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 16:28 ` Johannes Berg
2015-08-26 22:59 ` Simon Barber
[not found] ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2015-08-27 1:17 ` Guy Harris
[not found] ` <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-10 18:25 ` Guy Harris
[not found] ` <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-17 16:37 ` Johannes Berg [this message]
2019-12-10 23:51 ` Guy Harris
2019-12-11 8:32 ` Johannes Berg
2019-12-11 9:39 ` Krishna Chaitanya
2019-12-11 12:57 ` Johannes Berg
2019-12-11 13:20 ` Krishna Chaitanya
2019-12-20 21:56 ` Guy Harris
2015-09-17 16:32 ` Johannes Berg
2015-08-26 22:56 ` Simon Barber
Reply instructions:
You may reply publicly 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=1442507879.2821.9.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
--cc=realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=simon-vp0mx6+5gkqFX2APIN6yfw@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).