radiotap.netbsd.org archive mirror
 help / color / mirror / Atom feed
* A modified, and maybe final, proposal for an S1G header for RadioTap
@ 2019-04-14 15:57 Richard Sharpe
  2021-02-01 15:00 ` Richard Sharpe
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Richard Sharpe @ 2019-04-14 15:57 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, Aaron Lee, Tasheng Lin

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

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 |

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

[-- Attachment #2: pkt-gen.c --]
[-- Type: text/plain, Size: 3432 bytes --]

/*
 * A generic packet generator application.
 *
 * Copyright Richard Sharpe, 2019.
 *
 * You are welcome to use, modify, otherwise, this code.
 *
 * You will need libpcap installed.
 *
 * Create a Makefile with this:
 * 
 * all:
 *	cc -g -o pkt-gen pkt-gen.c -I . -lpcap
 *
 */

#include <errno.h>
#include <pcap/pcap.h>
#include <stdlib.h>
#include <string.h>

struct s1g_radiotap_hdr {
	uint16_t type;
	uint16_t len;
	uint16_t known;
	uint16_t data1;
	uint16_t data2;
	uint8_t ndp_type;
	uint8_t ndp_data[5];
} __attribute__((packed));

struct radiotap_hdr {
	uint8_t vers;
	uint8_t pad;
	uint16_t len;
	uint32_t presence_flags;
	uint32_t MAC_timestamp[2];
	uint8_t flags;
	uint8_t data_rate;
	uint16_t pad2;
	struct s1g_radiotap_hdr s1g_hdr;
} __attribute__((packed));

struct complete_pkt {
	struct radiotap_hdr radiotap;
	uint8_t pkt_data[26];
} __attribute__((packed));

uint8_t pkt_data[26] = { 0x1c, 0x0b, 0x00, 0x00, 0x02, 0x00, 0xeb, 0x4b,
			 0x02, 0x8b, 0x12, 0x52, 0xa7, 0x6b, 0x00, 0x62,
			 0x9c, 0x6b, 0x64, 0x4e, 0x35, 0xae, 0x05, 0x02,
			 0x00, 0x02 };

int main(int argc, char *argv[])
{
	int err = -1;
	pcap_t *pd = NULL;
	void *ctx = NULL;
	struct pcap_pkthdr hdr;
	struct timeval ts;
	pcap_dumper_t *dumper = NULL;
	struct complete_pkt pkt;

	if (argc < 2) {
		printf("Usage: %s <pcap-file-name>\n", argv[0]);
		return 1;
	}

	pd = pcap_open_dead(DLT_IEEE802_11_RADIO, 65535);
	if (pd == NULL) {
		fprintf(stderr, "Unable to open pcap device: %s\n",
			strerror(errno));
		return -1;
	}

	dumper = pcap_dump_open(pd, argv[1]);
        if (dumper == NULL) {
		fprintf(stderr, "Unable to create dump file %s: %s\n",
			argv[1], pcap_geterr(pd));
		goto close_pd;
	}

	/*
	 * Now create the comlete packet.
	 */
	pkt.radiotap.vers = 0;
	pkt.radiotap.pad = 0;
	pkt.radiotap.len = sizeof(struct radiotap_hdr);
	pkt.radiotap.presence_flags = 0x10000007;
	pkt.radiotap.MAC_timestamp[0] = 0x17860500;
	pkt.radiotap.MAC_timestamp[1] = 0x22ac9b1a;
	pkt.radiotap.flags = 0;
	pkt.radiotap.data_rate = 0x0c;
	pkt.radiotap.pad2 = 0xffff;
	pkt.radiotap.s1g_hdr.type = 32;
	pkt.radiotap.s1g_hdr.len = 12;
	pkt.radiotap.s1g_hdr.known = 0x0005; /* S1G PPDU forman and GU known */
	pkt.radiotap.s1g_hdr.data1 = 0x0020;
	pkt.radiotap.s1g_hdr.data2 = 0x0;
	pkt.radiotap.s1g_hdr.ndp_type = 0;
	pkt.radiotap.s1g_hdr.ndp_data[0] = 0;
	pkt.radiotap.s1g_hdr.ndp_data[1] = 0;
	pkt.radiotap.s1g_hdr.ndp_data[2] = 0;
	pkt.radiotap.s1g_hdr.ndp_data[3] = 0;
	pkt.radiotap.s1g_hdr.ndp_data[4] = 0;
	memcpy(pkt.pkt_data, pkt_data, sizeof(pkt.pkt_data));

	gettimeofday(&ts, NULL);
	hdr.ts = ts;
	hdr.caplen = sizeof(struct complete_pkt);
	hdr.len = sizeof(struct complete_pkt);

	pcap_dump((u_char *)dumper, &hdr, (u_char *)&pkt);

	/* Dump another with different values */
	pkt.radiotap.s1g_hdr.known = 0x0035;
	pkt.radiotap.s1g_hdr.data1 = 0xB421;

	pcap_dump((u_char *)dumper, &hdr, (u_char *)&pkt);

	pkt.radiotap.s1g_hdr.known = 0x0180;
	pkt.radiotap.s1g_hdr.data1 = 0;
	pkt.radiotap.s1g_hdr.ndp_type = 0;
	pkt.radiotap.s1g_hdr.ndp_data[0] = 0xe2;
	pkt.radiotap.s1g_hdr.ndp_data[1] = 0xd9;
	pkt.radiotap.s1g_hdr.ndp_data[2] = 0x03;
	pkt.radiotap.s1g_hdr.ndp_data[3] = 0x00;
	pkt.radiotap.s1g_hdr.ndp_data[4] = 0x80;

	hdr.caplen = sizeof(struct radiotap_hdr);
	hdr.len = sizeof(struct radiotap_hdr);

	pcap_dump((u_char *)dumper, &hdr, (u_char *)&pkt);

close_dumper:
	pcap_dump_close(dumper);
close_pd:
	pcap_close(pd);
	return err;
}

[-- Attachment #3: 0001-Add-an-S1G-field-as-well-as-add-some-Channel-values.patch --]
[-- Type: application/octet-stream, Size: 3643 bytes --]

From 615f45b78804fc369fdf4d63ab4b6f50aa1910a4 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 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/Channel.md   |  3 ++
 fields/S1G.md       | 68 +++++++++++++++++++++++++++++++++++++++++++++
 fields/suggested.md |  3 ++
 3 files changed, 74 insertions(+)
 create mode 100644 fields/S1G.md

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..6bc57b3
--- /dev/null
+++ b/fields/S1G.md
@@ -0,0 +1,68 @@
+---
+title: S1G
+categories: [suggested]
+---
+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 |
+
diff --git a/fields/suggested.md b/fields/suggested.md
index 32577d9..3b6e720 100644
--- a/fields/suggested.md
+++ b/fields/suggested.md
@@ -18,3 +18,6 @@ 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) |
+
+| **TLV type number |  **field** |
+| 32 | [S1G](/fields/S1G) |
-- 
2.19.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: A modified, and maybe final, proposal for an S1G header for RadioTap
  2019-04-14 15:57 A modified, and maybe final, proposal for an S1G header for RadioTap Richard Sharpe
@ 2021-02-01 15:00 ` Richard Sharpe
  2021-02-02 20:59 ` Johannes Berg
  2021-12-06 20:10 ` Johannes Berg
  2 siblings, 0 replies; 6+ messages in thread
From: Richard Sharpe @ 2021-02-01 15:00 UTC (permalink / raw)
  To: radiotap, Aaron Lee

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
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A modified, and maybe final, proposal for an S1G header for RadioTap
  2019-04-14 15:57 A modified, and maybe final, proposal for an S1G header for RadioTap Richard Sharpe
  2021-02-01 15:00 ` Richard Sharpe
@ 2021-02-02 20:59 ` Johannes Berg
  2021-02-04 17:57   ` Richard Sharpe
  2021-12-06 20:10 ` Johannes Berg
  2 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2021-02-02 20:59 UTC (permalink / raw)
  To: Richard Sharpe, radiotap, Ray Wang, Aaron Lee, Tasheng Lin

Hi Richard,

Couple of (last-minute!) comments ...

> Structure
> : u16 known, u16 data1, u16 data2, u8 ndp_type, u8[5] ndp_data;
> 
> Required Alignment
> : 4

If you only have u16 data, what's the value of 4-byte alignment?

> Is NDP indicates that this is an NDP frame, however, the content might
> not be known.

Should that have a note that the zero-length PSDU field should be set?
But if so, should that get a new sub-type for S1G NDP?

Otherwise:

> > **`0x0080`** | Is NDP, which means no packet data follows this header! |

this overlaps?

I guess it doesn't really matter though if that overlaps.

> > **`0x00C0`** | Number spatial streams: 0=1 Spatial stream, 1=2, ..
> 3=4 Spatial streams |

"Number of" I guess

johannes


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A modified, and maybe final, proposal for an S1G header for RadioTap
  2021-02-02 20:59 ` Johannes Berg
@ 2021-02-04 17:57   ` Richard Sharpe
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Sharpe @ 2021-02-04 17:57 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap, Ray Wang, Aaron Lee, Tasheng Lin

On Tue, Feb 2, 2021 at 1:00 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi Richard,
>
> Couple of (last-minute!) comments ...
>
> > Structure
> > : u16 known, u16 data1, u16 data2, u8 ndp_type, u8[5] ndp_data;
> >
> > Required Alignment
> > : 4
>
> If you only have u16 data, what's the value of 4-byte alignment?

Good point.

> > Is NDP indicates that this is an NDP frame, however, the content might
> > not be known.
>
> Should that have a note that the zero-length PSDU field should be set?
> But if so, should that get a new sub-type for S1G NDP?

Hmmm, I need to look at that again in light of how the S1G NDP stuff played out.

> Otherwise:
>
> > > **`0x0080`** | Is NDP, which means no packet data follows this header! |
>
> this overlaps?
>
> I guess it doesn't really matter though if that overlaps.

Will look at and fix.

> > > **`0x00C0`** | Number spatial streams: 0=1 Spatial stream, 1=2, ..
> > 3=4 Spatial streams |
>
> "Number of" I guess

OK. Will fix.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A modified, and maybe final, proposal for an S1G header for RadioTap
  2019-04-14 15:57 A modified, and maybe final, proposal for an S1G header for RadioTap Richard Sharpe
  2021-02-01 15:00 ` Richard Sharpe
  2021-02-02 20:59 ` Johannes Berg
@ 2021-12-06 20:10 ` Johannes Berg
  2021-12-06 22:12   ` Aaron - Jehun Lee
  2 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2021-12-06 20:10 UTC (permalink / raw)
  To: Richard Sharpe, radiotap, Ray Wang, Aaron Lee, Tasheng Lin

On Sun, 2019-04-14 at 08:57 -0700, Richard Sharpe wrote:
> Hi folks,
> 
> Here is an updated proposal for this header.
> 

I think we should just adopt this. Years have literally passed, and I'm
pretty sure it's actually used as-is in the wild.

Any objections? If not I'll go add it to the spec soon.

johannes

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: A modified, and maybe final, proposal for an S1G header for RadioTap
  2021-12-06 20:10 ` Johannes Berg
@ 2021-12-06 22:12   ` Aaron - Jehun Lee
  0 siblings, 0 replies; 6+ messages in thread
From: Aaron - Jehun Lee @ 2021-12-06 22:12 UTC (permalink / raw)
  To: Johannes Berg, Richard Sharpe, radiotap, Ray Wang, Tasheng Lin

Hi Johannes,

Thank you for your email. I have no objection.

Best,
Aaron
-----Original Message-----
From: Johannes Berg <johannes@sipsolutions.net> 
Sent: Monday, December 6, 2021 12:10 PM
To: Richard Sharpe <realrichardsharpe@gmail.com>; radiotap@radiotap.org; Ray Wang <rwang@wi-fi.org>; Aaron - Jehun Lee <jehun.lee@newracom.com>; Tasheng Lin <tlin@wi-fi.org>
Subject: Re: A modified, and maybe final, proposal for an S1G header for RadioTap

On Sun, 2019-04-14 at 08:57 -0700, Richard Sharpe wrote:
> Hi folks,
> 
> Here is an updated proposal for this header.
> 

I think we should just adopt this. Years have literally passed, and I'm pretty sure it's actually used as-is in the wild.

Any objections? If not I'll go add it to the spec soon.

johannes

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-12-06 23:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-14 15:57 A modified, and maybe final, proposal for an S1G header for RadioTap Richard Sharpe
2021-02-01 15:00 ` Richard Sharpe
2021-02-02 20:59 ` Johannes Berg
2021-02-04 17:57   ` Richard Sharpe
2021-12-06 20:10 ` Johannes Berg
2021-12-06 22:12   ` Aaron - Jehun Lee

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