Re: Correct radiotap header for 802.11ad

[Krishna Chaitanya <chaitanya.mgit@gmail.com>]

On Wed, Dec 11, 2019 at 2:02 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> ++ for the DMG discussion
>
> On Tue, 2019-12-10 at 15:51 -0800, Guy Harris wrote:
> > On Sep 17, 2015, at 9:37 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Reviving an old thread :-)
>
> > > 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.
> >
> > But a presumably-Linux system does appear to use it; see Wireshark bug
> >
> >       https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16272
> >
> > For now, I'll throw a hack into Wireshark to treat a signal >= 60 GHz
> > as meaning 11ad,
>
> I don't think that's quite right - you'll need to do something like >=
> 56 GHz.
>
> > but, again, should there be additional fields for 11ad?
>
> I would think so.
>
> On the one hand I think (and looking at the spec seems to confirm this)
> that basically DMG uses an MCS index. Now, the MCS radiotap field was
> designed for HT and has a lot of things that are not applicable (GI,
> STBC, etc.)
>
> OTOH, there are DMG-specific things that probably ought to be captured
> by a proper sniffer, like the PPDU type, training length, etc. Also,
> there's the thing with the "Extended SC MCS Indication field", which
> really also ought to be captured.
>
> Sadly, the only Linux implementation didn't bother adjusting any of this
> even in the Linux general stack (and I didn't pay enough attention to it
> at the beginning), so even the rate reporting to userspace is just the
> MCS index. This might actually be sufficient for the current uses
> (there's a conversion function to bandwidth too), though it doesn't seem
> quite applicable to the whole spec.
>
> For both the Linux userspace reporting and radiotap then, this
> completely ignores the existence of the MCSes 9.1 and 12.1-12.6, which
> cannot be captured in either format right now. Maybe the extended SC
> MCSes are just not used by equipment in the field?
>
They are used. Unfortunately, Linux-wireless doesn't have native support for DMG
wil6210 and our driver has to workaround by using HT IE's
(ieee80211_supported_band).
>
>
> In any case, to capture DMG properly I'd say we need a new radiotap
> field with at least
>  * (base) MCS
>  * Extended SC MCS bit
> and it should probably optionally cover the other possible fields as
> well
>  * Scrambler Initialization
>  * Length (?)
>  * Additional PPDU bit
>  * PPDU type bit
>  * Training Length
>  * Beam Tracking Request
>  * Last RSSI
>  * Turnaround
yes, we definitely need this, there are some additional fields in
11ay, but I guess that
discussion is for another time.