Radiotap header for S1G captures and associated changes and other definitions

Radiotap header for S1G captures and associated changes and other definitions

[Richard Sharpe]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

This is a third attempt at a RADIOTAP header for S1G captures.

Aaron Lee did the work in creating these definitions. I simply transcribed them.

The attached patch defines changes to the Channel field, 0-length-MPDU
field and a new S1G field.

There is also the associated definitions of the S1G NDP field which is
defined in 802.11ah-2016 Section 9.9.

1. Channel field:

3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
0x0008 for 900 MHz spectrum channels respectively.

2. 0-length MPDU field:

1 new value: 0x02 in the type value: 2 indicates that this is an S1G
NDP frame and that an S1G field is included in the Radiotap header..

3. The new S1G frame.

It consists of three 16-bit fields, an 8-bit field and a 40-bit field:

U16 known, U16 data1, U16 data2, U8 ndp_type, U8 ndp_data[5]

Known:
0x0001 S1G PPDU format known
0x0002 Response indication known
0x0004 Guard Interval known
0x0008 NSS known
0x0010 Bandwidth known
0x0020 MCS known
0x0040 Color known
0x0080 Is NDP
0x0100 NDP known
0xFE00 Reserved

Data1:
0x0003: S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG
0x000C: Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE,
2=NORMAL_RESPONSE, 3=LONG_RESPPNSE
0x0010: Reserved
0x0020: Guard interval: 0=Long GI, 1=Short GI
0x00C0: Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams
0x0F00: Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz, 5-15 reserved
0xF000:  MCS (MCS rate index, 0-10, 11-15 reserved)

Data2:
0x000F: Color: 0-7
0xFFF0: Reserved

NDP type:
0x00: NDP Control frame
0x01: NDP Management frame
0x02-0xFF: Reserved

NDP data:

These are as defined in 802.11ah-2016 Section 9.9 except that the top
two bits of data[4] are:

0x00: 1MHz
0x01: 2MHz
0x02-0x03: Reserved

The S1G NPD format is essentially from section 9.9 of 802.11ah-2016
with some additional syntactic sugar:

It is a 40-bit field.

In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 unused
bits. The used bits are defined in section 9.9 of 802.11ah-2016. A
2MHz NDP CMAC frame contains 37 used bits and one unused bit. Again,
the used bits are defined in 802.11ah-2016.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

[-- Attachment #2: 0001-Add-an-S1G-field-and-modify-the-0-length-PSDU-defini.patch --]
[-- Type: application/octet-stream, Size: 4104 bytes --]

From f7dcca714cc68f0c1b9c18701bb231b8e0dae674 Mon Sep 17 00:00:00 2001
From: Richard Sharpe <rsharpe@localhost.localdomain>
Date: Mon, 4 Mar 2019 18:31:40 -0800
Subject: [PATCH] Add an S1G field and modify the 0-length PSDU definition for
 S1G NDP info as well as add some Channel values.

After discussion with Johannes, this is what we have.

The author is Aaron Lee. Transcribed by Richard Sharpe.
Signed-off-by: Richard Sharpe <realrichardsharpe@gmail.com>
---
 fields/0-length-PSDU.md |  1 +
 fields/Channel.md       |  3 +++
 fields/S1G.md           | 67 +++++++++++++++++++++++++++++++++++++++++++++++++
 fields/suggested.md     |  1 +
 4 files changed, 72 insertions(+)
 create mode 100644 fields/S1G.md

diff --git a/fields/0-length-PSDU.md b/fields/0-length-PSDU.md
index 307cee0..7912601 100644
--- a/fields/0-length-PSDU.md
+++ b/fields/0-length-PSDU.md
@@ -23,4 +23,5 @@ The type field indicates the type of PPDU.
 | **type value** | **meaning** |
 | 0              | sounding PPDU |
 | 1              | data not captured (e.g. multi-user PPDU) |
+| 2              | S1G NDP CMAC frame - a 40-bit S1G NDP CMAC frame is in the S1G field|
 | 0xff           | vendor-specific |
diff --git a/fields/Channel.md b/fields/Channel.md
index 784c5c4..5747862 100644
--- a/fields/Channel.md
+++ b/fields/Channel.md
@@ -21,6 +21,9 @@ Currently, the following flags are defined:
 
 | **Mask** | **Meaning** |
 | 0x0010 | Turbo Channel |
+| 0x0002 | S1G 700MHz spectrum channel |
+| 0x0004 | S1G 800MHz spectrum channel |
+| 0x0008 | S1G 900MHz spectrum channel |
 | 0x0020 | CCK channel |
 | 0x0040 | OFDM channel |
 | 0x0080 | 2 GHz spectrum channel |
diff --git a/fields/S1G.md b/fields/S1G.md
new file mode 100644
index 0000000..e45cd76
--- /dev/null
+++ b/fields/S1G.md
@@ -0,0 +1,67 @@
+---
+title: S1G
+categories: [suggested]
+---
+Bit Number
+: 16
+
+Structure
+: u16 known, u16 data1, u16 data2, u8 ndp_type, u8[5] ndp_data;
+
+Required Alignment
+: 2
+
+Unit(s)
+: none
+
+The presence of this field indicates the frame was capture using an S1G phy.
+
+This field contains data to allow correct handling by programs like
+Wireshark etc.
+
+Is NDP indicates that this is an NDP frame, however, the content might not be known.
+
+## known
+
+| **`0x0001`** | S1G PPDU Format known |
+| **`0x0002`** | Response indication known |
+| **`0x0004`** | Guard interval known |
+| **`0x0008`** | NSS known | 
+| **`0x0010`** | Bandwidth known |
+| **`0x0020`** | MCS known |
+| **`0x0040`** | Color known |
+| **`0x0080`** | Is NDP |
+| **`0x0100`** | NDP content known |
+| **`0xFE00`** | Reserved |
+
+## data1
+
+| **`0x0003`** | S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG |
+| **`0x000C`** | Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE, 2=NORMAL_RESPONSE, 3=LONG_RESPPNSE |
+| **`0x0010`** | Reserved |
+| **`0x0020`** | Guard interval: 0=Long GI, 1=Short GI |
+| **`0x00C0`** | Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams |
+| **`0x0F00`** | Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz, 5-15 reserved |
+| **`0xF000`** | MCS (MCS rate index, 0-10, 11-15 reserved) |
+
+## data2
+
+| **`0x000F`** | Color: 0-7 |
+| **`0xFFF0`** | Reserved |
+
+## ndp_type
+
+This value is only defined if ndp_known is true.
+
+| **ndp_type value** | **Meaning** |
+| 0x00 | NDP Control frame |
+| 0x01 | NDP Management Frame |
+| 0x02-0xFF | Reserved |
+
+## ndp_data
+
+This value is only defined if ndp_known is true. The bytes are as defined in IEEE802.11ah, Section 9.9, except that ndp_data[4] is defined as:
+
+| **`0x3F`** | used and unused bits depending on the BW field and type |
+| **`0xC0`** | Bandwidth: 0 = 1Mhz, 1 = 2MHz, 2-3 Reserved |
+
diff --git a/fields/suggested.md b/fields/suggested.md
index 32577d9..ec598bb 100644
--- a/fields/suggested.md
+++ b/fields/suggested.md
@@ -18,3 +18,4 @@ This table lists the fields some OSes assigned by bit number:
 | 16 | [RTS retries](/fields/RTS retries), [RSSI](/fields/RSSI) |
 | 17 | [data retries](/fields/data retries) |
 | 18 | [XChannel](/fields/XChannel) |
+| 28 | [S1G](/fields/S1G) |
-- 
1.8.3.1

Re: Radiotap header for S1G captures and associated changes and other definitions

[Johannes Berg]

Hi Richard,

> 1. Channel field:
> 
> 3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
> 0x0008 for 900 MHz spectrum channels respectively.

How much space do we have there btw? We're going to get 6-7 GHz channels
soon ... perhaps we should just give up on this field and put the actual
frequency & bandwidth etc. somewhere? If we don't already ...

> 2. 0-length MPDU field:
> 
> 1 new value: 0x02 in the type value: 2 indicates that this is an S1G
> NDP frame and that an S1G field is included in the Radiotap header..

I'm not sure I'd go as far as saying that it must have an S1G field in
this case.

> 3. The new S1G frame.
> 
> It consists of three 16-bit fields, an 8-bit field and a 40-bit field:
> 
> U16 known, U16 data1, U16 data2, U8 ndp_type, U8 ndp_data[5]
> 
> Known:
> 0x0001 S1G PPDU format known
> 0x0002 Response indication known
> 0x0004 Guard Interval known
> 0x0008 NSS known
> 0x0010 Bandwidth known
> 0x0020 MCS known
> 0x0040 Color known
> 0x0080 Is NDP

Don't think you need "Is NDP" now with the 0-length field change?

> 0x0100 NDP known

Better reword to "NDP data known" I think. Actually, you probably need
to split into "NDP type known" and "NDP data known"? Not sure if that's
realistic though, to know one and not the other? But you have a lot of
bits so it doesn't hurt to split it either.

> 0xFE00 Reserved
> 
> Data1:
> 0x0003: S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG
> 0x000C: Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE,
> 2=NORMAL_RESPONSE, 3=LONG_RESPPNSE

typo - LONG_RESPONSE was intended?

> 0x0010: Reserved
> 0x0020: Guard interval: 0=Long GI, 1=Short GI
> 0x00C0: Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams
> 0x0F00: Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz, 5-15 reserved

You could make that 0x0700 and leave the 0x0800 bit reserved.

Not a big deal though since you have a lot of free bits in the 'known'
and 'data2' fields. But if you leave it reserved you could use it later
if needed as parsers wouldn't be using/showing it.

> 0xF000:  MCS (MCS rate index, 0-10, 11-15 reserved)
> 
> Data2:
> 0x000F: Color: 0-7

Similarly here, 0-7 fits into 3 bits.

> 0xFFF0: Reserved
> 
> NDP type:
> 0x00: NDP Control frame
> 0x01: NDP Management frame
> 0x02-0xFF: Reserved
> 
> NDP data:
> 
> These are as defined in 802.11ah-2016 Section 9.9 except that the top
> two bits of data[4] are:
> 
> 0x00: 1MHz
> 0x01: 2MHz
> 0x02-0x03: Reserved

Is it really worth packing this into the end? You could have lots of
space in e.g. the data2 or NDP type fields (I guess, you reserved lots
of values there).

> The S1G NPD format is essentially from section 9.9 of 802.11ah-2016
> with some additional syntactic sugar:
> 
> It is a 40-bit field.

Not sure I understand this sentence. What's the syntactic sugar in being
a 40-bit field?

> In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 unused
> bits. The used bits are defined in section 9.9 of 802.11ah-2016. A
> 2MHz NDP CMAC frame contains 37 used bits and one unused bit. Again,
> the used bits are defined in 802.11ah-2016.

Right.

However, these also come with a 1-bit "NDP indication", 4-bit CRC and 6-
bit tail; perhaps it should be at least *possible* to capture those too,
even if nobody might do that right now? Then you'd need a total of 48
bits for this, afaict.


I guess a more fundamental question would be whether we should treat
these as metadata or payload. Obviously here we're treating them as
metadata and saying (by way of the 0-length field) that there's no
payload. But perhaps these *should* in fact be the payload instead, and
not use the 0-length field at all?

I really don't know the answer to that. It seems fairly obvious that
this one is more convenient, and the format of those frames is very
specific to the S1G things, and they couldn't really be used outside of
S1G unlike the 802.11 header & frame. So I think I'm happy with this,
just wanted to note this design decision explicitly.

johannes

Re: Radiotap header for S1G captures and associated changes and other definitions

[Richard Sharpe]

On Tue, Mar 5, 2019 at 3:58 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > 1. Channel field:
> >
> > 3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
> > 0x0008 for 900 MHz spectrum channels respectively.
>
> How much space do we have there btw? We're going to get 6-7 GHz channels
> soon ... perhaps we should just give up on this field and put the actual
> frequency & bandwidth etc. somewhere? If we don't already ...

Yes, although that is possibly a more general question. S1G will
always be below 1GHz, I believe.

However, in general, I think we need a separate field that specifies
the BW as a string, and probably even one per antenna.

> > NDP type:
> > 0x00: NDP Control frame
> > 0x01: NDP Management frame
> > 0x02-0xFF: Reserved
> >
> > NDP data:
> >
> > These are as defined in 802.11ah-2016 Section 9.9 except that the top
> > two bits of data[4] are:
> >
> > 0x00: 1MHz
> > 0x01: 2MHz
> > 0x02-0x03: Reserved
>
> Is it really worth packing this into the end? You could have lots of
> space in e.g. the data2 or NDP type fields (I guess, you reserved lots
> of values there).
>
> > The S1G NPD format is essentially from section 9.9 of 802.11ah-2016
> > with some additional syntactic sugar:
> >
> > It is a 40-bit field.
>
> Not sure I understand this sentence. What's the syntactic sugar in being
> a 40-bit field?
>
> > In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 unused
> > bits. The used bits are defined in section 9.9 of 802.11ah-2016. A
> > 2MHz NDP CMAC frame contains 37 used bits and one unused bit. Again,
> > the used bits are defined in 802.11ah-2016.
>
> Right.
>
> However, these also come with a 1-bit "NDP indication", 4-bit CRC and 6-
> bit tail; perhaps it should be at least *possible* to capture those too,
> even if nobody might do that right now? Then you'd need a total of 48
> bits for this, afaict.
>
>
> I guess a more fundamental question would be whether we should treat
> these as metadata or payload. Obviously here we're treating them as
> metadata and saying (by way of the 0-length field) that there's no
> payload. But perhaps these *should* in fact be the payload instead, and
> not use the 0-length field at all?
>
> I really don't know the answer to that. It seems fairly obvious that
> this one is more convenient, and the format of those frames is very
> specific to the S1G things, and they couldn't really be used outside of
> S1G unlike the 802.11 header & frame. So I think I'm happy with this,
> just wanted to note this design decision explicitly.

I will clean up the others over the next few days, but yes, I went
back and forward between having the NDP info be a separate payload
versus placing it in the S1G header. Placing it in the S1G header is
more convenient but will mean moving code around over what we
currently have, however, that is relatively easy.

It is a matter of convenience.

A question for Aaron and the WFA folks, however, is: Is there utility
capturing the NDP indication, or is that already captured in IS NDP
above? Similarly, is it useful to capture the CRC and tail etc. Does
the hardware give you access to these extra fields?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

RE: Radiotap header for S1G captures and associated changes and other definitions

[yodazhong-Re5JQEeQqe8AvxtiuMwx3w]

Hi all,

Thank you for your valuable comments.
For the NDP related questions, yes. Hardware and its firmware can capture whole NDP
and get the NDP indication value.
And 802.11ah defines frequency spectrum from 750-950MHz; 700 for China, 800 for EU,
and 900 for others in general.

Best regards,
Aaron
-----Original Message-----
From: Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 
Sent: Tuesday, March 5, 2019 7:29 AM
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org; Ray Wang <rwang-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org>; Tasheng Lin <tlin-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org>; Aaron J. Lee <yodazhong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: Radiotap header for S1G captures and associated changes and other definitions

On Tue, Mar 5, 2019 at 3:58 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > 1. Channel field:
> >
> > 3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
> > 0x0008 for 900 MHz spectrum channels respectively.
>
> How much space do we have there btw? We're going to get 6-7 GHz 
> channels soon ... perhaps we should just give up on this field and put 
> the actual frequency & bandwidth etc. somewhere? If we don't already ...

Yes, although that is possibly a more general question. S1G will always be below 1GHz, I believe.

However, in general, I think we need a separate field that specifies the BW as a string, and probably even one per antenna.

> > NDP type:
> > 0x00: NDP Control frame
> > 0x01: NDP Management frame
> > 0x02-0xFF: Reserved
> >
> > NDP data:
> >
> > These are as defined in 802.11ah-2016 Section 9.9 except that the 
> > top two bits of data[4] are:
> >
> > 0x00: 1MHz
> > 0x01: 2MHz
> > 0x02-0x03: Reserved
>
> Is it really worth packing this into the end? You could have lots of 
> space in e.g. the data2 or NDP type fields (I guess, you reserved lots 
> of values there).
>
> > The S1G NPD format is essentially from section 9.9 of 802.11ah-2016 
> > with some additional syntactic sugar:
> >
> > It is a 40-bit field.
>
> Not sure I understand this sentence. What's the syntactic sugar in 
> being a 40-bit field?
>
> > In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 
> > unused bits. The used bits are defined in section 9.9 of 
> > 802.11ah-2016. A 2MHz NDP CMAC frame contains 37 used bits and one 
> > unused bit. Again, the used bits are defined in 802.11ah-2016.
>
> Right.
>
> However, these also come with a 1-bit "NDP indication", 4-bit CRC and 
> 6- bit tail; perhaps it should be at least *possible* to capture those 
> too, even if nobody might do that right now? Then you'd need a total 
> of 48 bits for this, afaict.
>
>
> I guess a more fundamental question would be whether we should treat 
> these as metadata or payload. Obviously here we're treating them as 
> metadata and saying (by way of the 0-length field) that there's no 
> payload. But perhaps these *should* in fact be the payload instead, 
> and not use the 0-length field at all?
>
> I really don't know the answer to that. It seems fairly obvious that 
> this one is more convenient, and the format of those frames is very 
> specific to the S1G things, and they couldn't really be used outside 
> of S1G unlike the 802.11 header & frame. So I think I'm happy with 
> this, just wanted to note this design decision explicitly.

I will clean up the others over the next few days, but yes, I went back and forward between having the NDP info be a separate payload versus placing it in the S1G header. Placing it in the S1G header is more convenient but will mean moving code around over what we currently have, however, that is relatively easy.

It is a matter of convenience.

A question for Aaron and the WFA folks, however, is: Is there utility capturing the NDP indication, or is that already captured in IS NDP above? Similarly, is it useful to capture the CRC and tail etc. Does the hardware give you access to these extra fields?

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

Re: Radiotap header for S1G captures and associated changes and other definitions

[Johannes Berg]

On Mon, 2019-03-04 at 19:18 -0800, Richard Sharpe wrote:
> This is a third attempt at a RADIOTAP header for S1G captures.

What's the status of this, were you going to resend?

Not sure I mentioned it before, but I think you shouldn't use bit 16 for
S1G, see below.

I just resent my proposal for TLV fields, and I also think we should get
that in before we add the S1G field, because ... we've run out of bits
in the first presence bitmap!

We're using all the bits 0-27 (other than 15 and 16 which are awkwardly
used for different things in different OSes).

Only bit 28 is free, bit 29 is the special "new radiotap namespace", bit
30 is the special "new vendor namespace", and bit 31 of course is the
extension.

Thus I think we should use bit 28 for the TLV switch so we won't always
have to generate an extension presence bitmap when we generate a TLV
type header.

What do you think?

johannes

Radiotap header for S1G captures and associated changes and other definitions

[Richard Sharpe]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Hi folks,

This is a second attempt at a RADIOTAP header for S1G captures.

Aaron Lee did the work in creating these definitions. I simply transcribed them.

The attached patch defines changes to the Channel field, 0-length-MPDU
field and a new S1G field.

There is also and associated definition for S1G NPD frames, which are
40-bit non-MAC frames transmitted by S1G STAs. I have included the
definition of those in this email, and they are essentially from
802.11ah-2016 with a little bit of helpful framing.

1. Channel field:

3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
0x0008 for 900 MHz spectrum channels respectively.

2. 0-length MPDU field:

1 new value: 0x02 in the type value: 2 indicates that an S1G NDP
40-bit frame follows.

Note, this seems weird. Maybe the name of the field needs changing to
non-MAC frame or something.

3. The new S1G frame.

It consists of three 16-bit fields:

U16 known, U16 data1, U16 data2

Known:
0x0001 S1G PPDU format known
0x0002 Response indication known
0x0004 Guard Interval known
0x0008 NSS known
0x0010 Bandwidth known
0x0020 MCS Known
0x0040 Color known
0xFF80 Reserved

Data1:
0x0003: S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG
0x000C: Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE,
2=NORMAL_RESPONSE, 3=LONG_RESPPNSE
0x0010: Reserved
0x0020: Guard interval: 0=Long GI, 1=Short GI
0x00C0: Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams
0x0F00: Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz, 5-15 reserved
0xF000:  MCS (MCS rate index, 0-10, 11-15 reserved)

Data2:
0x000F: Color: 0-7
0xFFF0: Reserved

The S1G NPD format is essentially from section 9.9 of 802.11ah-2016
with some additional syntactic sugar:

It is a 40-bit field.

The first 8 bits distinguishes between Management and Control frames
using the values 0x0F (management) and 0x20 (control).

The last two bits indicates the bandwidth, between 1MHz and 2MHz,

In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 unused
bits. The used bits are defined in section 9.9 of 802.11ah-2016. A
1MHz NDP CMAC frame contains 37 used bits and one unused bit. Again,
the used bits are defined in 802.11ah-2016.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

[-- Attachment #2: 0001-Add-an-S1G-field-and-modify-the-0-length-PSDU-defini.patch --]
[-- Type: application/octet-stream, Size: 3710 bytes --]

From ef99213c7235d4afe028331cd02b52cdb6b7b82f Mon Sep 17 00:00:00 2001
From: Richard Sharpe <rsharpe@localhost.localdomain>
Date: Thu, 31 Jan 2019 15:47:50 -0800
Subject: [PATCH] Add an S1G field and modify the 0-length PSDU definition for
 S1G NDP info as well as add some Channel values.

The author is Aaron Lee. Transcribed by Richard Sharpe.
Signed-off-by: Richard Sharpe <realrichardsharpe@gmail.com>
---
 fields/0-length-PSDU.md |  4 +++-
 fields/Channel.md       |  3 +++
 fields/S1G.md           | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 fields/suggested.md     |  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 fields/S1G.md

diff --git a/fields/0-length-PSDU.md b/fields/0-length-PSDU.md
index 307cee0..4af5564 100644
--- a/fields/0-length-PSDU.md
+++ b/fields/0-length-PSDU.md
@@ -16,11 +16,13 @@ Unit(s)
 
 The presence of this field indicates that there was no PSDU in or
 captured for this PPDU, only the PHY data is valid and the radiotap
-header is not followed by an 802.11 header.
+header is not followed by an 802.11 header, however, other types of frames
+may follow, like an S1G NDP frame, which is of fixed length.
 
 The type field indicates the type of PPDU.
 
 | **type value** | **meaning** |
 | 0              | sounding PPDU |
 | 1              | data not captured (e.g. multi-user PPDU) |
+| 2              | S1G NDP CMAC frame - a 40-bit S1G NDP CMAC frame follows |
 | 0xff           | vendor-specific |
diff --git a/fields/Channel.md b/fields/Channel.md
index 784c5c4..5747862 100644
--- a/fields/Channel.md
+++ b/fields/Channel.md
@@ -21,6 +21,9 @@ Currently, the following flags are defined:
 
 | **Mask** | **Meaning** |
 | 0x0010 | Turbo Channel |
+| 0x0002 | S1G 700MHz spectrum channel |
+| 0x0004 | S1G 800MHz spectrum channel |
+| 0x0008 | S1G 900MHz spectrum channel |
 | 0x0020 | CCK channel |
 | 0x0040 | OFDM channel |
 | 0x0080 | 2 GHz spectrum channel |
diff --git a/fields/S1G.md b/fields/S1G.md
new file mode 100644
index 0000000..8d325cf
--- /dev/null
+++ b/fields/S1G.md
@@ -0,0 +1,46 @@
+---
+title: S1G
+categories: [suggested]
+---
+Bit Number
+: 16
+
+Structure
+: u16 known, u16 data1, u16 data2
+
+Required Alignment
+: 2
+
+Unit(s)
+: none
+
+The presence of this field indicates the frame was capture using an S1G phy.
+
+This field contains data to allow correct handling by programs like
+Wireshark etc.
+
+## known
+
+| **`0x0001`** | S1G PPDU Format known |
+| **`0x0002`** | Response indication known |
+| **`0x0004`** | Guard interval known |
+| **`0x0008`** | NSS known | 
+| **`0x0010`** | Bandwidth known |
+| **`0x0020`** | MCS known |
+| **`0x0040`** | Color known |
+| **`0xFF80`** | Reserved |
+
+## data1
+
+| **`0x0003`** | S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG |
+| **`0x000C`** | Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE, 2=NORMAL_RESPONSE, 3=LONG_RESPPNSE |
+| **`0x0010`** | Reserved |
+| **`0x0020`** | Guard interval: 0=Long GI, 1=Short GI |
+| **`0x00C0`** | Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams |
+| **`0x0F00`** | Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz, 5-15 reserved |
+| **`0xF000`** | MCS (MCS rate index, 0-10, 11-15 reserved) |
+
+## data2
+
+| **`0x000F`** | Color: 0-7 |
+| **`0xFFF0`** | Reserved |
diff --git a/fields/suggested.md b/fields/suggested.md
index 32577d9..ec598bb 100644
--- a/fields/suggested.md
+++ b/fields/suggested.md
@@ -18,3 +18,4 @@ This table lists the fields some OSes assigned by bit number:
 | 16 | [RTS retries](/fields/RTS retries), [RSSI](/fields/RSSI) |
 | 17 | [data retries](/fields/data retries) |
 | 18 | [XChannel](/fields/XChannel) |
+| 28 | [S1G](/fields/S1G) |
-- 
1.8.3.1