Correct radiotap header for 802.11ad

Correct radiotap header for 802.11ad

[Richard Sharpe]

Hi folks,

I have some 802.11ad captures because of some fixes to the Wireshark
802.11 dissector I am looking at doing.

One thing I notice is that the radiotap header contains both a Channel field
and an MCS field.

The Present flags say that Flags are present, Channel is present and
HT Information is present.

The channel frequency is 60480MHz which seems to be reasonable.

The MCS field says that the MCS index is present and that index is 0.

It seems to me that this last field is perhaps incorrect, because the
radiotap information dissector claims that the PHY type is 802.11n,
and that seems to come about because the radiotap header use the MCS
index info to claim that the PHY type was 802.11n.

Should I be letting the capture hardware vendor know that they are
generating the wrong info?

I probably should also have some override stuff in the radiotap
dissector that uses the frequency field to correctly set the PHY type.

Any comments?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I have some 802.11ad captures because of some fixes to the Wireshark
> 802.11 dissector I am looking at doing.
> 
> One thing I notice is that the radiotap header contains both a Channel field
> and an MCS field.

That is to be expected for 11n packets.

> The Present flags say that Flags are present, Channel is present and
> HT Information is present.

By "HT Information" do you mean "the MCS field"?

The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.

> The channel frequency is 60480MHz which seems to be reasonable.
> 
> The MCS field says that the MCS index is present and that index is 0.
> 
> It seems to me that this last field is perhaps incorrect, because the
> radiotap information dissector claims that the PHY type is 802.11n,
> and that seems to come about because the radiotap header use the MCS
> index info to claim that the PHY type was 802.11n.

Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.

From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:

	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.

which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.

> Should I be letting the capture hardware vendor know that they are
> generating the wrong info?

I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)

Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

Re: Correct radiotap header for 802.11ad

[Richard Sharpe]

On Sat, Aug 22, 2015 at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
>
> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I have some 802.11ad captures because of some fixes to the Wireshark
>> 802.11 dissector I am looking at doing.
>>
>> One thing I notice is that the radiotap header contains both a Channel field
>> and an MCS field.
>
> That is to be expected for 11n packets.
>
>> The Present flags say that Flags are present, Channel is present and
>> HT Information is present.
>
> By "HT Information" do you mean "the MCS field"?

I suspect so. The Present flags are 0x0a000800. The HT information
present flag appears to indicate that MCS information is present.

> The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.
>
>> The channel frequency is 60480MHz which seems to be reasonable.
>>
>> The MCS field says that the MCS index is present and that index is 0.
>>
>> It seems to me that this last field is perhaps incorrect, because the
>> radiotap information dissector claims that the PHY type is 802.11n,
>> and that seems to come about because the radiotap header use the MCS
>> index info to claim that the PHY type was 802.11n.
>
> Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.
>
> From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
>
>         The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
>
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.
>
>> Should I be letting the capture hardware vendor know that they are
>> generating the wrong info?
>
> I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)
>
> Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

I suspect that it would but I do not have any captures where the
A-MPDU Status is listed as present.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Aug 22, 2015, at 3:06 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Sat, Aug 22, 2015 at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
>> 
>> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 
>>> The Present flags say that Flags are present, Channel is present and
>>> HT Information is present.
>> 
>> By "HT Information" do you mean "the MCS field"?
> 
> I suspect so. The Present flags are 0x0a000800. The HT information
> present flag appears to indicate that MCS information is present.

The Wireshark dissector refers to the MCS field as the "HT information" field when dissecting the presence flags.

(Note that Wireshark is not the authoritative reference for anything in radiotap.)

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Aug 22, 2015, at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:

> From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
> 
> 	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
> 
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.

For what it's worth, it appears that the wil6210 driver:

	https://wireless.wiki.kernel.org/en/users/drivers/wil6210

uses the MCS field and its mcs value for 11ad.  It can also be configured to supply raw "PHY data" with a vendor-namespace field.

So code that processes radiotap headers, such as Wireshark's radiotap-header dissector, will have to interpret packets with an MCS field and a channel frequence in the 11ad range as being 11ad packets, and treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
> 
> For what it's worth, it appears that the wil6210 driver:
> 
> 	https://wireless.wiki.kernel.org/en/users/drivers/wil6210
> 
> uses the MCS field and its mcs value for 11ad.  It can also be 
> configured to supply raw "PHY data" with a vendor-namespace field.
> 
> So code that processes radiotap headers, such as Wireshark's radiotap
> -header dissector, will have to interpret packets with an MCS field 
> and a channel frequence in the 11ad range as being 11ad packets, and 
> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.

That just seems really lazy though - I think we should rather fix that
driver and define a proper 60G radiotap field.

johannes

Re: Correct radiotap header for 802.11ad

[Richard Sharpe]

On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
>>
>> For what it's worth, it appears that the wil6210 driver:
>>
>>       https://wireless.wiki.kernel.org/en/users/drivers/wil6210
>>
>> uses the MCS field and its mcs value for 11ad.  It can also be
>> configured to supply raw "PHY data" with a vendor-namespace field.
>>
>> So code that processes radiotap headers, such as Wireshark's radiotap
>> -header dissector, will have to interpret packets with an MCS field
>> and a channel frequence in the 11ad range as being 11ad packets, and
>> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
>
> That just seems really lazy though - I think we should rather fix that
> driver and define a proper 60G radiotap field.

Can I suggest something like the following, although we have defined
the presence flags as a UINT32 for the moment in Wireshark:

--- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
13:34:23.633866699 -0700
+++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
@@ -190,6 +190,11 @@
  * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
  *
  * Contains VHT information about this frame.
+ *
+ * IEEE80211_RADIOTAP_DMG       u8, u8
+ *
+ *      Contains DMG information about the frame. Currently presence flags
+ *      and the MCS index, if present.
  */
 enum ieee80211_radiotap_type {
  IEEE80211_RADIOTAP_TSFT = 0,
@@ -214,6 +219,7 @@
  IEEE80211_RADIOTAP_MCS = 19,
  IEEE80211_RADIOTAP_AMPDU_STATUS = 20,
  IEEE80211_RADIOTAP_VHT = 21,
+ IEEE80211_RADIOTAP_DMG = 22,

  /* valid in every it_present bitmap, even vendor namespaces */
  IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,

Also, there is the matter of whether or not we need to indicate Static
Tone Pairing and Dynamic Tone Pairing as that is a bit in the PHY
header and is needed to make sense of MCS values 13-17, maybe.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

On Mon, 2015-08-24 at 09:21 -0700, Richard Sharpe wrote:
> On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
> > > 
> > > For what it's worth, it appears that the wil6210 driver:
> > > 
> > >       https://wireless.wiki.kernel.org/en/users/drivers/wil6210
> > > 
> > > uses the MCS field and its mcs value for 11ad.  It can also be
> > > configured to supply raw "PHY data" with a vendor-namespace field.
> > > 
> > > So code that processes radiotap headers, such as Wireshark's radiotap
> > > -header dissector, will have to interpret packets with an MCS field
> > > and a channel frequence in the 11ad range as being 11ad packets, and
> > > treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
> > 
> > That just seems really lazy though - I think we should rather fix that
> > driver and define a proper 60G radiotap field.
> 
> Can I suggest something like the following, although we have defined
> the presence flags as a UINT32 for the moment in Wireshark:
> 
> --- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
> 13:34:23.633866699 -0700
> +++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
> @@ -190,6 +190,11 @@
>   * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
>   *
>   * Contains VHT information about this frame.
> + *
> + * IEEE80211_RADIOTAP_DMG       u8, u8
> + *
> + *      Contains DMG information about the frame. Currently presence flags
> + *      and the MCS index, if present.
> 

I'm not sure that'll work - the format can't really be variable, so
having presence flags and just the MCS isn't useful (since if you don't
know the MCS, then you might as well not include the DMG field at all)

We need to define the full set of information we might want, but I'm
not nearly familiar enough with DMG to suggest what might be needed.

johannes

Re: Correct radiotap header for 802.11ad

[Simon Barber]

I've never seen a capture file with a correct or useful A-MPDU field! 
I'd also like to know more information - such as what amount of padding 
was there between MPDUs in the A-MPDU.

Simon

On 8/22/2015 1:59 PM, Guy Harris wrote:
> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I have some 802.11ad captures because of some fixes to the Wireshark
>> 802.11 dissector I am looking at doing.
>>
>> One thing I notice is that the radiotap header contains both a Channel field
>> and an MCS field.
> That is to be expected for 11n packets.
>
>> The Present flags say that Flags are present, Channel is present and
>> HT Information is present.
> By "HT Information" do you mean "the MCS field"?
>
> The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.
>
>> The channel frequency is 60480MHz which seems to be reasonable.
>>
>> The MCS field says that the MCS index is present and that index is 0.
>>
>> It seems to me that this last field is perhaps incorrect, because the
>> radiotap information dissector claims that the PHY type is 802.11n,
>> and that seems to come about because the radiotap header use the MCS
>> index info to claim that the PHY type was 802.11n.
> Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.
>
>  From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
>
> 	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
>
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.
>
>> Should I be letting the capture hardware vendor know that they are
>> generating the wrong info?
> I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)
>
> Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

Re: Correct radiotap header for 802.11ad

[Simon Barber]

The HT and VHT fields are missing various bits of phy layer info, and 
are defined missing enough bits for other fields. I've always thought It 
would be much simpler if these fields could convey the whole SIGNAL bits 
from the PLCP header, along with a mask in case it's not all available. 
The drivers I've seen have the whole PLCP SIGNAL field available.

Simon

On 8/24/2015 9:21 AM, Richard Sharpe wrote:
> On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>> On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
>>> For what it's worth, it appears that the wil6210 driver:
>>>
>>>        https://wireless.wiki.kernel.org/en/users/drivers/wil6210
>>>
>>> uses the MCS field and its mcs value for 11ad.  It can also be
>>> configured to supply raw "PHY data" with a vendor-namespace field.
>>>
>>> So code that processes radiotap headers, such as Wireshark's radiotap
>>> -header dissector, will have to interpret packets with an MCS field
>>> and a channel frequence in the 11ad range as being 11ad packets, and
>>> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
>> That just seems really lazy though - I think we should rather fix that
>> driver and define a proper 60G radiotap field.
> Can I suggest something like the following, although we have defined
> the presence flags as a UINT32 for the moment in Wireshark:
>
> --- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
> 13:34:23.633866699 -0700
> +++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
> @@ -190,6 +190,11 @@
>    * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
>    *
>    * Contains VHT information about this frame.
> + *
> + * IEEE80211_RADIOTAP_DMG       u8, u8
> + *
> + *      Contains DMG information about the frame. Currently presence flags
> + *      and the MCS index, if present.
>    */
>   enum ieee80211_radiotap_type {
>    IEEE80211_RADIOTAP_TSFT = 0,
> @@ -214,6 +219,7 @@
>    IEEE80211_RADIOTAP_MCS = 19,
>    IEEE80211_RADIOTAP_AMPDU_STATUS = 20,
>    IEEE80211_RADIOTAP_VHT = 21,
> + IEEE80211_RADIOTAP_DMG = 22,
>
>    /* valid in every it_present bitmap, even vendor namespaces */
>    IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,
>
> Also, there is the matter of whether or not we need to indicate Static
> Tone Pairing and Dynamic Tone Pairing as that is a bit in the PHY
> header and is needed to make sense of MCS values 13-17, maybe.
>

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Aug 26, 2015, at 3:59 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:

> The HT and VHT fields are missing various bits of phy layer info, and are defined missing enough bits for other fields. I've always thought It would be much simpler if these fields could convey the whole SIGNAL bits from the PLCP header, along with a mask in case it's not all available. The drivers I've seen have the whole PLCP SIGNAL field available.

So that's the L-SIG bits from 20.3.9.3.5 "L-SIG definition", and either the HT-SIG bits from 20.3.9.4.3 "HT-SIG definition" or the VHT-SIG-A bits from 11ac's 22.3.8.3.3 "VHT-SIG-A definition" and the VHT-SIG-B bits from 11ac's 22.3.8.3.6 "VHT-SIG-B definition"?

And for 11ad, would it be the bits from 21.5.3.1.1 "General"?

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Aug 26, 2015, at 6:17 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:

> On Aug 26, 2015, at 3:59 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:
> 
>> The HT and VHT fields are missing various bits of phy layer info, and are defined missing enough bits for other fields. I've always thought It would be much simpler if these fields could convey the whole SIGNAL bits from the PLCP header, along with a mask in case it's not all available. The drivers I've seen have the whole PLCP SIGNAL field available.
> 
> So that's the L-SIG bits from 20.3.9.3.5 "L-SIG definition"

I.e., L_DATARATE and L_LENGTH?

> and either the HT-SIG bits from 20.3.9.4.3 "HT-SIG definition"

I.e.:

	the MCS index

	CBW 20/40

	HT Length

	Smoothing

	Not Sounding

	Aggregation (PPDU contains an A-MPDU)

	STBC

	FEC coding

	Short GI

	N(ESS)

	CRC of the bits

	Tail Bits

The ones that aren't in the MCS field or the A-MPDU field are:

	HT Length - is that just the length of the data following the radiotap header?

	Smoothing

	Not Sounding

	CRC - is this of any interest?

	Tail Bits - always 0, so these are presumably not of interest

Can:

	whether "20" means "20", "20L", or "20U";

	HT mixed vs. greenfield;

both of which are available from the MCS field, be determined from the PLCP header?

Or is what "20" means not fully determinable for received packets, so that "20L", "20U", and "40" are indistinguishable, similar to what the Radiotap spec for the VHT field says?

20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format of the HT-SIG of an HT-greenfield format frame is identical to the HT-SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if that information can be determined for received frames, it sounds as if greenfield vs. mixed *can't* be determined from the HT-SIG bits.

> or the VHT-SIG-A bits from 11ac's 22.3.8.3.3 "VHT-SIG-A definition" and the VHT-SIG-B bits from 11ac's 22.3.8.3.6 "VHT-SIG-B definition"?

I.e.:

	BW

	STBC

	Group ID

	NSTS/Partial AID

	TXOPS_PS_NOT_ALLOWED

	Short GI

	Short GI NSYM Disambiguation

	SU/MU[0] Coding

	LDPC Extra OFDM Symbol

	SU VHT-MCS/MU[1-3] Coding

	Beamformed

	CRC

	Tail Bits

The ones that aren't in the MCS field are:

	CRC - is this of any interest?

	Tail Bits - always 0, so these are presumably not of interest

The spec for the VHT field says that NSTS "can be calculated from the NSS for that user and the STBC flag" and that, for received frames, the only bandwidth information you get is 20/40/80/160, which is presumably what you can get from BW.

For *transmitted* frames, I guess you have more control over how it's transmitted, which is presumably why there's a VHT field rather than just a PLCP header field.

I.e., as radiotap is used for transmission, it needs to include at least some of the parameters to the PHY service's transmission operation, which may not be available in the PLCP header.

> And for 11ad, would it be the bits from 21.5.3.1.1 "General"?

I.e.:

	Scrambler Initialization - probably not of interest

	MCS

	Length - is this just the length of the data following the radiotap header?

	Additional PPDU

	Packet Type

	Training Length

	Aggregation (PPDU contains an A-MPDU)

	Beam Tracking Request

	Tone Pairing Type

	DTP Indicator

	Last RSSI

	Turnaround

	HCS (a CRC)

So do we need all of those?

And is there anything more that would be needed for *injected* 11ad frames?  If so, that's an argument for a "DMG" field containing the interesting information from the PLCP header combined with information necessary for injected frames?

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

On Wed, 2015-08-26 at 15:59 -0700, Simon Barber wrote:
> The HT and VHT fields are missing various bits of phy layer info, and 
> 
> are defined missing enough bits for other fields. I've always thought It 
> would be much simpler if these fields could convey the whole SIGNAL bits 
> from the PLCP header, along with a mask in case it's not all available. 
> The drivers I've seen have the whole PLCP SIGNAL field available.
> 

What drivers have you been looking at? Most I've seen don't actually
have it.

I don't really object to this proposal though - the mask would be very
much needed though and one might have to re-construct the signal field
from available data.

johannes

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

On Thu, 2015-09-10 at 11:25 -0700, Guy Harris wrote:
> 
> The ones that aren't in the MCS field or the A-MPDU field are:
> 
> 	HT Length - is that just the length of the data following 
> the radiotap header?

I don't think so - at least not with A-MPDU.

> 	Smoothing
> 
> 	Not Sounding
> 
> 	CRC - is this of any interest?
> 
> 	Tail Bits - always 0, so these are presumably not of 
> interest
> 
> Can:
> 
> 	whether "20" means "20", "20L", or "20U";
> 
> 	HT mixed vs. greenfield;
> 
> both of which are available from the MCS field, be determined from 
> the PLCP header?
> 
> Or is what "20" means not fully determinable for received packets, so 
> that "20L", "20U", and "40" are indistinguishable, similar to what 
> the Radiotap spec for the VHT field says?

I have a hard time seeing 20L/20U being distinguishable if you're
hearing those while tuned to a 20 MHz channel, but if you're tuned to a
40 MHz channel then perhaps that's possible - likely not from the PLCP
though since that would have to look like a regular 20 MHz transmission
for purposes of somebody picking it up on a 20 MHz channel? I'm not
really all that familiar with the PHY details though.

> 20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format 
> of the HT-SIG of an HT-greenfield format frame is identical to the HT
> -SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if 
> that information can be determined for received frames, it sounds as 
> if greenfield vs. mixed *can't* be determined from the HT-SIG bits.

You can know whether or not it was preceded by a compat preamble
though.

> For *transmitted* frames, I guess you have more control over how it's 
> transmitted, which is presumably why there's a VHT field rather than 
> just a PLCP header field.
> 
> I.e., as radiotap is used for transmission, it needs to include at 
> least some of the parameters to the PHY service's transmission 
> operation, which may not be available in the PLCP header.

That's also a good point - having to build a PLCP signal field for
transmission would be somewhat painful, especially if you just want to
control some part of the transmission.

> And is there anything more that would be needed for *injected* 11ad 
> frames?  If so, that's an argument for a "DMG" field containing the 
> interesting information from the PLCP header combined with 
> information necessary for injected frames?

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.

johannes

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Sep 17, 2015, at 9:37 AM, Johannes Berg <johannes@sipsolutions.net> wrote:

> 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, but, again, should there be additional fields for 11ad?

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

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


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

Re: Correct radiotap header for 802.11ad

[Krishna Chaitanya]

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.

Re: Correct radiotap header for 802.11ad

[Johannes Berg]

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

Re: Correct radiotap header for 802.11ad

[Krishna Chaitanya]

On Wed, Dec 11, 2019 at 6:28 PM Johannes Berg <johannes@sipsolutions.net> 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.

Re: Correct radiotap header for 802.11ad

[Guy Harris]

On Dec 11, 2019, at 12:32 AM, Johannes Berg <johannes@sipsolutions.net> wrote:

> 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 :-)

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.