RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* 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 --]

^ 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

* 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]     ` <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

* 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

* 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 --]

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

end of thread, back to index

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

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git