++ 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? 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 johannes
