From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 67E2D84D7B for ; Wed, 11 Dec 2019 09:39:32 +0000 (UTC) Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id baFg_Qacs_yD for ; Wed, 11 Dec 2019 09:39:31 +0000 (UTC) Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 716CE84C2B for ; Wed, 11 Dec 2019 09:39:31 +0000 (UTC) Received: by mail-yw1-xc42.google.com with SMTP id n184so1950856ywc.3 for ; Wed, 11 Dec 2019 01:39:31 -0800 (PST) MIME-Version: 1.0 References: <38F46E1D-1C4A-48DC-A906-9522006E8474@alum.mit.edu> <1606812C-649C-4C06-ABE0-AE2F4474BCD0@alum.mit.edu> <1440402013.3735.1.camel@sipsolutions.net> <55DE44EB.6080603@superduper.net> <126B842D-05EA-4510-BC9B-DB1A4AABEC12@alum.mit.edu> <1135A126-6A5A-4C84-A52D-13C0387609CC@alum.mit.edu> <1442507879.2821.9.camel@sipsolutions.net> <4cf0c2a4a2d1cd92dff4f1a791d74523e446cf01.camel@sipsolutions.net> In-Reply-To: <4cf0c2a4a2d1cd92dff4f1a791d74523e446cf01.camel@sipsolutions.net> From: Krishna Chaitanya Date: Wed, 11 Dec 2019 15:09:19 +0530 Message-ID: Subject: Re: Correct radiotap header for 802.11ad Content-Type: text/plain; charset="UTF-8" Sender: radiotap-owner@radiotap.org List-Id: List-Unsubscribe: Content-Transfer-Encoding: 8bit To: Johannes Berg Cc: Guy Harris , "radiotap@netbsd.org" , Simon Barber , Richard Sharpe , linux-wireless , Maya Erez , wil6210@qti.qualcomm.com On Wed, Dec 11, 2019 at 2:02 PM Johannes Berg 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 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.