Re: A modified, and maybe final, proposal for an S1G header for RadioTap

On Sun, Apr 14, 2019 at 8:57 AM Richard Sharpe
<[email protected]> wrote:
>
> Hi folks,
>
> Here is an updated proposal for this header.
>
> It has undergone some modifications.
>
> I include the patch to the radiotap git repo as well as a small C
> program for generating such headers.
>
> I have moved to using TLVs and have integrated Johannes' code for
> handling Radiotap RLVs into Wireshark 2.6.2 and used my test program
> to test the code.
>
> The test code only generates three frames so far, but it could be
> modified to provide broarder coverage.
>
> I suggest that people making Radiotap proposals in the future should
> also include code for generating such headers as it is pretty easy to
> do so and makes it easier for people writing parsers.
>
> We want to move forward with this and I have code now that dissects it
> in Wireshark. Of course, that code is easy to change as well.
>
> Here are the changes for the Channel field. Add three seemingly unused va=
lues:
>
> | 0x0002 | S1G 700MHz spectrum channel |
> | 0x0004 | S1G 800MHz spectrum channel |
> | 0x0008 | S1G 900MHz spectrum channel |
>
> Here is the new S1G field. It uses TLV Type value 32.
>
> Note, we have also explicitly decided to place the Null Data Packet
> (NDP) info into the S1G header. This reduces the amount of change
> needed in dissectors but it does mean that the zero_length_ppdu
> infrastructure that is already in Wireshark for example.
>
> TLV Type Number
> : 32
>
> Structure
> : u16 known, u16 data1, u16 data2, u8 ndp_type, u8[5] ndp_data;
>
> Required Alignment
> : 4
>
> Unit(s)
> : none
>
> The presence of this field indicates the frame was capture using an S1G p=
hy.
>
> 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, which means no packet data follows this header! =
|
> | **`0x0100`** | NDP content known |
> | **`0xFE00`** | Reserved |
>
> ## data1
>
> | **`0x0003`** | S1G PPDU Format: 0=3DS1G_1M, 1=3DS1G_SHORT, 2=3DS1G_LONG=
 |
> | **`0x000C`** | Response indication: 0=3DNO_RESPONSE, 1=3DNDP_RESPONSE,
> 2=3DNORMAL_RESPONSE, 3=3DLONG_RESPPNSE |
> | **`0x0010`** | Reserved |
> | **`0x0020`** | Guard interval: 0=3DLong GI, 1=3DShort GI |
> | **`0x00C0`** | Number spatial streams: 0=3D1 Spatial stream, 1=3D2, ..
> 3=3D4 Spatial streams |
> | **`0x0700`** | Bandwidth: 0=3D1MHz, 1=3D2MHz, 2=3D4MHz, 3=3D8MHz, 4=3D1=
6MHz,
> 5-15 reserved |
> | **`0x0800`** | Reserved |
> | **`0xF000`** | MCS (MCS rate index, 0-10, 11-15 reserved) |
>
> ## data2
>
> | **`0x0007`** | Color: 0-7 |
> | **`0xFFF8`** | 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 =3D 1Mhz, 1 =3D 2MHz, 2-3 Reserved |

Can we move forward and accept this? It's been over a year and I am
trying to get code merged with Wireshark that uses this proposal.

--=20
Regards,
Richard Sharpe
(=E4=BD=95=E4=BB=A5=E8=A7=A3=E6=86=82=EF=BC=9F=E5=94=AF=E6=9C=89=E6=9D=9C=
=E5=BA=B7=E3=80=82--=E6=9B=B9=E6=93=8D)(=E4=BC=A0=E8=AF=B4=E6=9D=9C=E5=BA=
=B7=E6=98=AF=E9=85=92=E7=9A=84=E5=8F=91=E6=98=8E=E8=80=85)