RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Proposal for an S1G header for radiotap
@ 2019-02-01  0:02 Richard Sharpe
       [not found] ` <CACyXjPwCydx6fumWdXdLvg-StsRcALBLc5+4fCsGDaC7tcZXCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Sharpe @ 2019-02-01  0:02 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw
  Cc: Aaron J. Lee, Ray Wang, tlin-+OaQ/Okkt+3YtjvyW6yDsg

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

Hi folks,

Attached is a git format-patch patch that contains a proposal for an S1G header.

This proposal was created by Aaron Lee and underwent a couple of
rounds of modifications among the WFA folks.

All I have done here is to transcribe it to the format required by the
documentation web site. Hopefully I have not changed any intent.

Below is some feedback from Johannes about the proposal so he does not
have to retype it along with some comments from me.

We should try to get this finalized as quickly as possible as quite a
bit of work is going on in this area.

Those who are interested in this topic should join the mailing list
because people may forget to reply-all!

> Channel field: This is a really old field, almost certainly somebody
> somewhere uses those bits they suggest already ... but I guess if
> wireshark doesn't parse them then that doesn't really matter, so I guess
> that'd be OK. I'd probably suggest using higher bits anyway, which are
> less likely to already be used.
>
> HALOW field: Mostly looks fine.
>
> I think the NDP indication (0x10 in data1) should probably be moved out
> into the 0-length psdu field we already have, so we don't need to handle
> special cases for it this in wireshark and other dissectors. The known
> bit for that (in known field) makes no sense anyway because clearly you
> have to know whether a packet was NDP or not. Unless I'm completely
> misunderstanding the meaning of this field.

The issue may be that an NDP actually carries non-MAC data. 25 bits in
the case of 1MHz NDPs and 37 bits in the case of 2MHz NDPs. If we can
shoehorn them into the 0-length-PSDU maybe we should.

> The "NSS" field is only 2 bits and can only capture values 0-3, not 1-4,
> so they probably mean the value inside is NSS-1, or NSS==field+1. Fine,
> but needs clarification.

Yeah. I unilaterally clarified that, so Aaron will have to look at it
and correct me if I am wrong.

> Aggregation bit isn't clear - don't they do things similarly to normal
> HT/VHT/HE A-MPDU and could re-use that field for aggregation? That can
> (optionally) also hold whether it was first/last and a cookie which
> frames belong together in an aggregation, so that's useful to have. IMHO
> should be moved to A-MPDU unless somebody can really explain why they
> need something special.
>
> And with that it easily fits into 2 u16 fields rather than 3 (actually
> it fits now even) so might be something to consider, though I don't
> really think space is much of a concern.

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

[-- Attachment #2: 0001-Add-an-S1G-field.patch --]
[-- Type: application/octet-stream, Size: 2890 bytes --]

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

* Re: Proposal for an S1G header for radiotap
       [not found] ` <CACyXjPwCydx6fumWdXdLvg-StsRcALBLc5+4fCsGDaC7tcZXCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2019-02-01 11:33   ` Johannes Berg
       [not found]     ` <8d1bb1c53c670e7cfddfc0cf2f5e2447b2ee2ecb.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2019-02-01 11:33 UTC (permalink / raw)
  To: Richard Sharpe, radiotap-sUITvd46vNxg9hUCZPvPmw
  Cc: Aaron J. Lee, Ray Wang, tlin-+OaQ/Okkt+3YtjvyW6yDsg

Hi Richard,

> Attached is a git format-patch patch that contains a proposal for an S1G header.
> 
> This proposal was created by Aaron Lee and underwent a couple of
> rounds of modifications among the WFA folks.
> 
> All I have done here is to transcribe it to the format required by the
> documentation web site. Hopefully I have not changed any intent.

Thanks for doing this! :)

> Below is some feedback from Johannes about the proposal so he does not
> have to retype it along with some comments from me.

:-)

Some *additional* feedback below - please do check my previous note
about aggregation handling, this is very unclear to me.


> > I think the NDP indication (0x10 in data1) should probably be moved out
> > into the 0-length psdu field we already have, so we don't need to handle
> > special cases for it this in wireshark and other dissectors. The known
> > bit for that (in known field) makes no sense anyway because clearly you
> > have to know whether a packet was NDP or not. Unless I'm completely
> > misunderstanding the meaning of this field.
> 
> The issue may be that an NDP actually carries non-MAC data. 25 bits in
> the case of 1MHz NDPs and 37 bits in the case of 2MHz NDPs. If we can
> shoehorn them into the 0-length-PSDU maybe we should.

Oh. Maybe not then. How would these bits even be represented in
wireshark though?

Clearly, the 25/37 bits are not part of the radiotap header proposal
right now, but if they're non-MAC data they probably should be?

I'd almost think we should be doing something like:

 * add a new "S1G NDP" sub-item to "0-length PSDU" field, even if now
   strictly it's no longer "0-length" but more like "no-MSDU"... which
   really is the effect in wireshark anyway
 * remove NDP from the S1G field
 * add a separate radiotap field for S1G NDP data, containing a length
   bit and 37 data bits?

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

That seems misplaced, should be after "Turbo Channel" I guess.

But also like I said above, some research on prior use of these bits
would be useful.
Looking at FreeBSD:
https://github.com/freebsd/freebsd/blob/master/sys/net80211/ieee80211_radiotap.h

they seem to have a few *higher* bits, but not lower ones. Maybe we can
risk it.

johannes

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

* Re: Proposal for an S1G header for radiotap
       [not found]     ` <8d1bb1c53c670e7cfddfc0cf2f5e2447b2ee2ecb.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2019-02-01 18:35       ` Richard Sharpe
       [not found]         ` <CACyXjPzc--Deaecx9HuV5i0jyO5uUKFOqEeUaWWv3oYXqBqc8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Sharpe @ 2019-02-01 18:35 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Aaron J. Lee, Ray Wang,
	tlin-+OaQ/Okkt+3YtjvyW6yDsg

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by the
> > documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does not
> > have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration
relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016
correctly.

In which case, we already have an A-MPDU header but we might need some
changes. Perhaps the WFA folks or Aaron can comment on this/

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

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

* RE: Proposal for an S1G header for radiotap
       [not found]         ` <CACyXjPzc--Deaecx9HuV5i0jyO5uUKFOqEeUaWWv3oYXqBqc8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2019-02-01 22:03           ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w
  2019-02-01 23:04             ` Ray Wang
  2019-02-05  9:17             ` Johannes Berg
  0 siblings, 2 replies; 8+ messages in thread
From: yodazhong-Re5JQEeQqe8AvxtiuMwx3w @ 2019-02-01 22:03 UTC (permalink / raw)
  To: Richard Sharpe, Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, tlin-+OaQ/Okkt+3YtjvyW6yDsg

Hi Johannes and Richard,

Thank you for your work and great comments.

For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
If there's pre-defined field for VHT single MPDU, we could use that.

For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU 
for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
So I think we could add S1G NDP frames under "0-length PSDU" field.

--
Best,
Aaron J. Lee

-----Original Message-----
From: Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 
Sent: Friday, February 1, 2019 10:35 AM
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org; Aaron J. Lee <yodazhong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Ray Wang <rwang-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org>; tlin-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org
Subject: Re: Proposal for an S1G header for radiotap

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of 
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by 
> > the documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does 
> > not have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note 
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016 correctly.

In which case, we already have an A-MPDU header but we might need some changes. Perhaps the WFA folks or Aaron can comment on this/

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

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

* RE: Proposal for an S1G header for radiotap
  2019-02-01 22:03           ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w
@ 2019-02-01 23:04             ` Ray Wang
       [not found]               ` <CY1PR07MB27160AEE154215058A2CA4F2FF920-p80jK0/XGTb2cgXex6xO0uFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  2019-02-05  9:17             ` Johannes Berg
  1 sibling, 1 reply; 8+ messages in thread
From: Ray Wang @ 2019-02-01 23:04 UTC (permalink / raw)
  To: yodazhong-Re5JQEeQqe8AvxtiuMwx3w, Richard Sharpe, Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Tasheng Lin

Hi Johannes and Richard,

As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can be seen the field is defined in SIG-2 of SIG field of S1G_SHORT preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG field of S1G_1M preamble.

If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B, and not in HE-SIG-A.

From the spec perspective regarding the Aggregation field, 802.11ah is different from 802.11n/ac/ax.

As you pointed out, Richard, if the existing field can be reused it might need some changes. If defining a new one, the existing one probably also needs to be handled. 

What would you suggest is the best way to tackle it?


Thanks,
Ray


-----Original Message-----
From: yodazhong@gmail.com [mailto:yodazhong@gmail.com] 
Sent: Friday, February 01, 2019 2:04 PM
To: 'Richard Sharpe' <realrichardsharpe@gmail.com>; 'Johannes Berg' <johannes@sipsolutions.net>
Cc: radiotap@radiotap.org; Ray Wang <rwang@wi-fi.org>; Tasheng Lin <tlin@wi-fi.org>
Subject: RE: Proposal for an S1G header for radiotap

Hi Johannes and Richard,

Thank you for your work and great comments.

For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
If there's pre-defined field for VHT single MPDU, we could use that.

For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
So I think we could add S1G NDP frames under "0-length PSDU" field.

--
Best,
Aaron J. Lee

-----Original Message-----
From: Richard Sharpe <realrichardsharpe@gmail.com>
Sent: Friday, February 1, 2019 10:35 AM
To: Johannes Berg <johannes@sipsolutions.net>
Cc: radiotap@radiotap.org; Aaron J. Lee <yodazhong@gmail.com>; Ray Wang <rwang@wi-fi.org>; tlin@wi-fi.org
Subject: Re: Proposal for an S1G header for radiotap

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of 
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by 
> > the documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does 
> > not have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note 
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016 correctly.

In which case, we already have an A-MPDU header but we might need some changes. Perhaps the WFA folks or Aaron can comment on this/

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


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

* Re: Proposal for an S1G header for radiotap
  2019-02-01 22:03           ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w
  2019-02-01 23:04             ` Ray Wang
@ 2019-02-05  9:17             ` Johannes Berg
  1 sibling, 0 replies; 8+ messages in thread
From: Johannes Berg @ 2019-02-05  9:17 UTC (permalink / raw)
  To: yodazhong-Re5JQEeQqe8AvxtiuMwx3w, Richard Sharpe
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Ray Wang, tlin-+OaQ/Okkt+3YtjvyW6yDsg

Hi,

> For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
> If there's pre-defined field for VHT single MPDU, we could use that.

Since it's kind of packed into an A-MPDU header, we have indeed added
the A-MPDU field for this to capture the EOF bit in VHT single MPDU.

> For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU 
> for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
> So I think we could add S1G NDP frames under "0-length PSDU" field.

Sounds good to me. It would mean wireshark shows no PSDU.

johannes

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

* Re: Proposal for an S1G header for radiotap
       [not found]               ` <CY1PR07MB27160AEE154215058A2CA4F2FF920-p80jK0/XGTb2cgXex6xO0uFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2019-02-05  9:55                 ` Johannes Berg
       [not found]                   ` <885a63e846a5c08b111601dfd25bf352c3763538.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2019-02-05  9:55 UTC (permalink / raw)
  To: Ray Wang, yodazhong-Re5JQEeQqe8AvxtiuMwx3w, Richard Sharpe
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Tasheng Lin

Hi,

> As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can
> be seen the field is defined in SIG-2 of SIG field of S1G_SHORT
> preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG
> field of S1G_1M preamble.
> 
> If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same
> field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B,
> and not in HE-SIG-A.
> 
> From the spec perspective regarding the Aggregation field, 802.11ah is
> different from 802.11n/ac/ax.

Well, OK. But we still use the A-MPDU field for HT/VHT/HE, even if those
are also different. We've gone for a more semantic view I guess, and you
can easily distinguish which kind of frame you had by the presence of
HT/VHT/HE fields and/or channel information.

> As you pointed out, Richard, if the existing field can be reused it
> might need some changes. If defining a new one, the existing one
> probably also needs to be handled. 
> 
> What would you suggest is the best way to tackle it?

Can you say what you actually want to capture for aggregation data? So
far you only had an "aggregation" bit, which could be easily indicated
by the presence of the A-MPDU field. But the A-MPDU reference number in
radiotap, which is something that obviously doesn't even exist in the
802.11 spec, would make sense so you know which PSDUs belonged into the
same aggregate.

johannes

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

* RE: Proposal for an S1G header for radiotap
       [not found]                   ` <885a63e846a5c08b111601dfd25bf352c3763538.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2019-02-05 19:19                     ` Ray Wang
  0 siblings, 0 replies; 8+ messages in thread
From: Ray Wang @ 2019-02-05 19:19 UTC (permalink / raw)
  To: Johannes Berg, yodazhong-Re5JQEeQqe8AvxtiuMwx3w, Richard Sharpe
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Tasheng Lin

Hi Johannes,

Thank you so much for your insight!

I agree with you that it is only an "aggregation" bit, The currently defined A-MPDU status field should be sufficient for that purpose as long as the SIG and SIG-A fields can be decoded in the corresponding S1G preambles, and A-MPDU status is populated or not populated accordingly.


Thanks,
Ray


-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Tuesday, February 05, 2019 1:55 AM
To: Ray Wang <rwang@wi-fi.org>; yodazhong@gmail.com; 'Richard Sharpe' <realrichardsharpe@gmail.com>
Cc: radiotap@radiotap.org; Tasheng Lin <tlin@wi-fi.org>
Subject: Re: Proposal for an S1G header for radiotap

Hi,

> As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can 
> be seen the field is defined in SIG-2 of SIG field of S1G_SHORT 
> preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG 
> field of S1G_1M preamble.
> 
> If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same 
> field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B, 
> and not in HE-SIG-A.
> 
> From the spec perspective regarding the Aggregation field, 802.11ah is 
> different from 802.11n/ac/ax.

Well, OK. But we still use the A-MPDU field for HT/VHT/HE, even if those are also different. We've gone for a more semantic view I guess, and you can easily distinguish which kind of frame you had by the presence of HT/VHT/HE fields and/or channel information.

> As you pointed out, Richard, if the existing field can be reused it 
> might need some changes. If defining a new one, the existing one 
> probably also needs to be handled.
> 
> What would you suggest is the best way to tackle it?

Can you say what you actually want to capture for aggregation data? So far you only had an "aggregation" bit, which could be easily indicated by the presence of the A-MPDU field. But the A-MPDU reference number in radiotap, which is something that obviously doesn't even exist in the
802.11 spec, would make sense so you know which PSDUs belonged into the same aggregate.

johannes


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

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-01  0:02 Proposal for an S1G header for radiotap Richard Sharpe
     [not found] ` <CACyXjPwCydx6fumWdXdLvg-StsRcALBLc5+4fCsGDaC7tcZXCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-01 11:33   ` Johannes Berg
     [not found]     ` <8d1bb1c53c670e7cfddfc0cf2f5e2447b2ee2ecb.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-02-01 18:35       ` Richard Sharpe
     [not found]         ` <CACyXjPzc--Deaecx9HuV5i0jyO5uUKFOqEeUaWWv3oYXqBqc8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-01 22:03           ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w
2019-02-01 23:04             ` Ray Wang
     [not found]               ` <CY1PR07MB27160AEE154215058A2CA4F2FF920-p80jK0/XGTb2cgXex6xO0uFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-02-05  9:55                 ` Johannes Berg
     [not found]                   ` <885a63e846a5c08b111601dfd25bf352c3763538.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-02-05 19:19                     ` Ray Wang
2019-02-05  9:17             ` 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