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

[Richard Sharpe <realrichardsharpe@gmail.com>]

On Sun, Apr 14, 2019 at 8:57 AM Richard Sharpe
<realrichardsharpe@gmail.com> 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 values:
>
> | 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 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, which means no packet data follows this header! |
> | **`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 |
> | **`0x0700`** | Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz,
> 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 = 1Mhz, 1 = 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.

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