* Radiotap header for S1G captures and associated changes and other definitions @ 2019-03-02 1:59 Richard Sharpe 0 siblings, 0 replies; 6+ messages in thread From: Richard Sharpe @ 2019-03-02 1:59 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Aaron J. Lee, Tasheng Lin [-- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Radiotap header for S1G captures and associated changes and other definitions
@ 2019-03-05 3:18 Richard Sharpe
[not found] ` <CACyXjPy-Lr143wcWaLkv-xgs9Ebc0j8pYfw8MzMXNEv2tLA0Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Richard Sharpe @ 2019-03-05 3:18 UTC (permalink / raw)
To: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Tasheng Lin, Aaron J. Lee
[-- 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
^ permalink raw reply related [flat|nested] 6+ messages in thread[parent not found: <CACyXjPy-Lr143wcWaLkv-xgs9Ebc0j8pYfw8MzMXNEv2tLA0Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Radiotap header for S1G captures and associated changes and other definitions [not found] ` <CACyXjPy-Lr143wcWaLkv-xgs9Ebc0j8pYfw8MzMXNEv2tLA0Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2019-03-05 11:58 ` Johannes Berg [not found] ` <56728a565c1f84862615f8804881bf72b7d12511.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 2019-04-09 8:58 ` Johannes Berg 1 sibling, 1 reply; 6+ messages in thread From: Johannes Berg @ 2019-03-05 11:58 UTC (permalink / raw) To: Richard Sharpe, radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Tasheng Lin, Aaron J. Lee 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <56728a565c1f84862615f8804881bf72b7d12511.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* Re: Radiotap header for S1G captures and associated changes and other definitions [not found] ` <56728a565c1f84862615f8804881bf72b7d12511.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> @ 2019-03-05 15:29 ` Richard Sharpe [not found] ` <CACyXjPxL1Jr7xXCh9tDBaORB5YyiJH7Zb2H+sKsz3mjUCbxkkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Richard Sharpe @ 2019-03-05 15:29 UTC (permalink / raw) To: Johannes Berg Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Tasheng Lin, Aaron J. Lee 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 (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CACyXjPxL1Jr7xXCh9tDBaORB5YyiJH7Zb2H+sKsz3mjUCbxkkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* RE: Radiotap header for S1G captures and associated changes and other definitions [not found] ` <CACyXjPxL1Jr7xXCh9tDBaORB5YyiJH7Zb2H+sKsz3mjUCbxkkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2019-03-06 8:07 ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w 0 siblings, 0 replies; 6+ messages in thread From: yodazhong-Re5JQEeQqe8AvxtiuMwx3w @ 2019-03-06 8:07 UTC (permalink / raw) To: 'Richard Sharpe', 'Johannes Berg' Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, 'Ray Wang', 'Tasheng Lin' 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 (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Radiotap header for S1G captures and associated changes and other definitions [not found] ` <CACyXjPy-Lr143wcWaLkv-xgs9Ebc0j8pYfw8MzMXNEv2tLA0Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2019-03-05 11:58 ` Johannes Berg @ 2019-04-09 8:58 ` Johannes Berg 1 sibling, 0 replies; 6+ messages in thread From: Johannes Berg @ 2019-04-09 8:58 UTC (permalink / raw) To: Richard Sharpe, radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Tasheng Lin, Aaron J. Lee 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-09 8:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-02 1:59 Radiotap header for S1G captures and associated changes and other definitions Richard Sharpe
2019-03-05 3:18 Richard Sharpe
[not found] ` <CACyXjPy-Lr143wcWaLkv-xgs9Ebc0j8pYfw8MzMXNEv2tLA0Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-05 11:58 ` Johannes Berg
[not found] ` <56728a565c1f84862615f8804881bf72b7d12511.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-03-05 15:29 ` Richard Sharpe
[not found] ` <CACyXjPxL1Jr7xXCh9tDBaORB5YyiJH7Zb2H+sKsz3mjUCbxkkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-06 8:07 ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w
2019-04-09 8:58 ` Johannes Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).