On Wed, Dec 11, 2019 at 2:02 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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.
