++ 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 <[email protected]> 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
On Wed, Dec 11, 2019 at 2:02 PM Johannes Berg <[email protected]> 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 <[email protected]> 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.
On Wed, 2019-12-11 at 15:09 +0530, Krishna Chaitanya wrote:
>
> > 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).
You make it sound like that some sort of thing that Linux cannot really
do better. That's far from the truth! We keep extending this (HT, VHT,
HE recently) and there's no fundamental reason we couldn't do extensions
for DMG. It's just that nobody who actually has a driver for Linux
bothered doing so!
> > 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.
Somebody (@QCA I guess, I don't have any functioning driver/hardware for
Linux for this) really should sit down and define the extensions to
cfg80211/nl80211 to capture the data properly, and a radiotap extension.
None of that is hard, I've done it for VHT before and HE recently.
johannes
On Wed, Dec 11, 2019 at 6:28 PM Johannes Berg <[email protected]> wrote:
>
> On Wed, 2019-12-11 at 15:09 +0530, Krishna Chaitanya wrote:
> >
> > > 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).
>
> You make it sound like that some sort of thing that Linux cannot really
> do better. That's far from the truth! We keep extending this (HT, VHT,
> HE recently) and there's no fundamental reason we couldn't do extensions
> for DMG. It's just that nobody who actually has a driver for Linux
> bothered doing so!
Sorry, that wasn't my intent, as there is a single upstream driver I guess
it was easier to workaround than to properly add support. I agree that
it shouldn't
be hard, may be we can do it properly for 11ay.
> > > 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.
>
> Somebody (@QCA I guess, I don't have any functioning driver/hardware for
> Linux for this) really should sit down and define the extensions to
> cfg80211/nl80211 to capture the data properly, and a radiotap extension.
> None of that is hard, I've done it for VHT before and HE recently.
On Dec 11, 2019, at 12:32 AM, Johannes Berg <[email protected]> wrote:
> On Tue, 2019-12-10 at 15:51 -0800, Guy Harris wrote:
>> On Sep 17, 2015, at 9:37 AM, Johannes Berg <[email protected]> wrote:
>
> Reviving an old thread :-)
Yes - it came up with the Wireshark bug in question.
>> 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.
Yes - there's a macro in Wireshark to test whether a frequency is in the 11ad range; it was testing for frequencies between 57 and 66 GHz. I changed the code to use that.
I also changed it to test for 57 to 71 GHz; apparently, some regulatory domains have added (US) or may add (Canada, EU) more frequencies to the range allowed.