[RFA] HE support

[RFA] HE support

[Johannes Berg]

Hi,

It looks like the spec etc. has matured sufficiently to standardise the
radiotap for HE. Richard Sharpe has also contributed an implementation
for wireshark, and we have an implementation for our driver to report
(a subset of) the information.

Rather than copy/paste all the information into the email, here are the
links to the three newly defined fields.
http://www.radiotap.org/fields/HE
http://www.radiotap.org/fields/HE-MU
http://www.radiotap.org/fields/HE-MU-other-user

I just made a minor change here to delete the duplicated field, and add
an RU offset field (with known flag, of course).

Our implementation for Linux is in this tree:

https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/

related commits:
17df37ef01e234f06458ba6a8ca35303a4323db0
9dadcd648cb0e4dd64fb0df87257bbf1abeb5c19
a3e502d6096bb2b82550027324084c17602b56cd
a76d55a9481e2c7136bf72a4c7682048a0331aef
edb94a27eac211e0dd66920919895d7a27539d32
e374d21c07c23d391c913cc3a61f728df4089253

fdea7e21cd1a743232b70c370b1bb1199d487598
fabf74cdf60527eb2d5f76362fd40ba135853aa3
a10e644921c2d6b5ced56bb44fa2ff312ffae982
5126862ce3cea626fb0f9b4918e8b5d77803f6ba

(but you can just look at the code in net/mac80211/rx.c and
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c)

We'll bring that upstream once radiotap is adopted.

Richard Sharpe's wireshark code is even partially merged already, see
here:
https://code.wireshark.org/review/#/c/25479/
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=731a901a3e25839ef3e0d89a0a21edc69ae474df
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=5f6571913b74c251abb45d2fec8c66f3c7cbe36d
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=8d6202df4559d144bc8edc6fdf4bfa6112fe746f


So let's also start 3 weeks commenting period for this, I think whoever
is interested probably already saw it anyway :-)

johannes

Re: [RFA] HE support

[Johannes Berg]

On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:

> Rather than copy/paste all the information into the email, here are the
> links to the three newly defined fields.
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU
> http://www.radiotap.org/fields/HE-MU-other-user
> 
> I just made a minor change here to delete the duplicated field, and add
> an RU offset field (with known flag, of course).

Oops, I have to make another update to this - we need a
"primary/secondary 80 MHz bit" (along with validity).

I think I'll put that into data2 bits 0/31, any objections?

johannes

Re: [RFA] HE support

[Johannes Berg]

On Tue, 2018-02-20 at 10:37 +0100, Johannes Berg wrote:
> On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:
> 
> > Rather than copy/paste all the information into the email, here are the
> > links to the three newly defined fields.
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU
> > http://www.radiotap.org/fields/HE-MU-other-user
> > 
> > I just made a minor change here to delete the duplicated field, and add
> > an RU offset field (with known flag, of course).
> 
> Oops, I have to make another update to this - we need a
> "primary/secondary 80 MHz bit" (along with validity).
> 
> I think I'll put that into data2 bits 0/31, any objections?

Just found another thing too.

In HE-MU, I had defined:
flags1: 0x0080: Bandwidth from SIG-A known
flags2: 0x0007: Bandwidth from SIG-A

Where this was intended to be like in the spec, which means:
 0 - 20 MHz non-puncturing
 1 - 40 MHz non-puncturing
 2 - 80 MHz non-puncturing
 3 - 160/80+80 MHz non-puncturing
 4/5/6/7 - the various puncturing modes


I think it'd be better to split this:
flags1: 0x0080: reserved
flags2: 0x0003: bandwidth from bw field in HE-SIG-A with the values
                 0 - 20 MHz
                 1 - 40 MHz
                 2 - 80 MHz
                 3 - 160/80+80 MHz
flags2: 0x0004: bandwidth from bw field in HE-SIG-A known
flags2: 0x0008: preamble puncturing from bw field in HE-SIG-A known
flags2: 0x0300: preamble puncturing from bw field in HE-SIG-A,
                with the values
                 0 - non-puncturing mode
                 1 - punctured secondary 20 MHz
                     (in primary 80 MHz if applicable)
                     [maps to HE-SIG-A bandwidth values 4 or 6]
                 2 - punctured but primary 40 MHz is presented
                     (in primary 80 MHz if applicable)
                     [maps to HE-SIG-A bandwidth values 5 or 7]

Richard, did you do any work on the HE-MU field yet that would collide
with such a change?

johannes

Re: [RFA] HE support

[Richard Sharpe]

On Tue, Feb 20, 2018 at 5:01 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Tue, 2018-02-20 at 10:37 +0100, Johannes Berg wrote:
>> On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:
>>
>> > Rather than copy/paste all the information into the email, here are the
>> > links to the three newly defined fields.
>> > http://www.radiotap.org/fields/HE
>> > http://www.radiotap.org/fields/HE-MU
>> > http://www.radiotap.org/fields/HE-MU-other-user
>> >
>> > I just made a minor change here to delete the duplicated field, and add
>> > an RU offset field (with known flag, of course).
>>
>> Oops, I have to make another update to this - we need a
>> "primary/secondary 80 MHz bit" (along with validity).
>>
>> I think I'll put that into data2 bits 0/31, any objections?
>
> Just found another thing too.
>
> In HE-MU, I had defined:
> flags1: 0x0080: Bandwidth from SIG-A known
> flags2: 0x0007: Bandwidth from SIG-A
>
> Where this was intended to be like in the spec, which means:
>  0 - 20 MHz non-puncturing
>  1 - 40 MHz non-puncturing
>  2 - 80 MHz non-puncturing
>  3 - 160/80+80 MHz non-puncturing
>  4/5/6/7 - the various puncturing modes
>
>
> I think it'd be better to split this:
> flags1: 0x0080: reserved
> flags2: 0x0003: bandwidth from bw field in HE-SIG-A with the values
>                  0 - 20 MHz
>                  1 - 40 MHz
>                  2 - 80 MHz
>                  3 - 160/80+80 MHz
> flags2: 0x0004: bandwidth from bw field in HE-SIG-A known
> flags2: 0x0008: preamble puncturing from bw field in HE-SIG-A known
> flags2: 0x0300: preamble puncturing from bw field in HE-SIG-A,
>                 with the values
>                  0 - non-puncturing mode
>                  1 - punctured secondary 20 MHz
>                      (in primary 80 MHz if applicable)
>                      [maps to HE-SIG-A bandwidth values 4 or 6]
>                  2 - punctured but primary 40 MHz is presented
>                      (in primary 80 MHz if applicable)
>                      [maps to HE-SIG-A bandwidth values 5 or 7]
>
> Richard, did you do any work on the HE-MU field yet that would collide
> with such a change?

I have, but:

1. It's WIP, so it has not been merged yet, and
2. It looks like maybe an hour's work at most to fix it.

So, I would say, accuracy is more important.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: [RFA] HE support

[Johannes Berg]

On Tue, 2018-02-20 at 06:59 -0800, Richard Sharpe wrote:
> 
> > I think it'd be better to split this:
> > flags1: 0x0080: reserved
> > flags2: 0x0003: bandwidth from bw field in HE-SIG-A with the values
> >                  0 - 20 MHz
> >                  1 - 40 MHz
> >                  2 - 80 MHz
> >                  3 - 160/80+80 MHz
> > flags2: 0x0004: bandwidth from bw field in HE-SIG-A known
> > flags2: 0x0008: preamble puncturing from bw field in HE-SIG-A known
> > flags2: 0x0300: preamble puncturing from bw field in HE-SIG-A,
> >                 with the values
> >                  0 - non-puncturing mode
> >                  1 - punctured secondary 20 MHz
> >                      (in primary 80 MHz if applicable)
> >                      [maps to HE-SIG-A bandwidth values 4 or 6]
> >                  2 - punctured but primary 40 MHz is presented
> >                      (in primary 80 MHz if applicable)
> >                      [maps to HE-SIG-A bandwidth values 5 or 7]
> > 
> > Richard, did you do any work on the HE-MU field yet that would collide
> > with such a change?
> 
> I have, but:
> 
> 1. It's WIP, so it has not been merged yet, and
> 2. It looks like maybe an hour's work at most to fix it.

Ok. Yeah, shouldn't be so hard to fix.

> So, I would say, accuracy is more important.

It's not really *inaccurate* as such, but it seems it'd be easier to
understand - and perhaps some devices would have the bandwidth but not
the puncturing mode available after decoding, for example.

I'll change it like that and resend the whole proposal.

johannes

Re: [RFA] HE support

[Richard Sharpe]

On Tue, Feb 20, 2018 at 1:37 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:
>
>> Rather than copy/paste all the information into the email, here are the
>> links to the three newly defined fields.
>> http://www.radiotap.org/fields/HE
>> http://www.radiotap.org/fields/HE-MU
>> http://www.radiotap.org/fields/HE-MU-other-user
>>
>> I just made a minor change here to delete the duplicated field, and add
>> an RU offset field (with known flag, of course).
>
> Oops, I have to make another update to this - we need a
> "primary/secondary 80 MHz bit" (along with validity).
>
> I think I'll put that into data2 bits 0/31, any objections?

I have just posted a review for this and for the RU Allocation Offset changes.

With luck they should get into 2.5.1.

https://code.wireshark.org/review/#/c/25927

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: [RFA] HE support

[Johannes Berg]

Ok, new attempt:

> It looks like the spec etc. has matured sufficiently to standardise the
> radiotap for HE. Richard Sharpe has also contributed an implementation
> for wireshark, and we have an implementation for our driver to report
> (a subset of) the information.
> 
> Rather than copy/paste all the information into the email, here are the
> links to the three newly defined fields.
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU
> http://www.radiotap.org/fields/HE-MU-other-user

This is updated, with the following changes:

 * primary/secondary 80 MHz known & value bit
 * fixed bug with # of HE-SIG-B Symbols/MU-MIMO users known (duplicate)
 * split HE-MU HE-SIG-A bandwidth into bandwidth/puncturing

I guess that'll restart 3 weeks, even if it's basically merged into
wireshark etc. anyway so not really changeable at this point :-)

johannes

Re: [RFA] HE support

[Johannes Berg]

On Tue, 2018-02-20 at 17:42 +0100, Johannes Berg wrote:
> 
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU

Huh, looks like I've overdone it ...

The HE field and HE-MU field both define the # of HE LTF symbols ...

I'll remove it from the HE-MU field.

johannes

Re: [RFA] HE support

[Johannes Berg]

On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:
> 
> http://www.radiotap.org/fields/HE-MU

Ugh, this yet again turned out to be incomplete - I missed that the RU
stuff is duplicated for 160 MHz transmissions, so this can only capture
one of the 80 MHz parts.

Probably the best way to solve this would be just change the field to
the structure

u16 flags1
u16 flags2
u8  RU[8]

and then use up all the reserved bits for the needed known/center 26-
tone bits (need an additional 6 bits, which we _just_ have).

However, this means that the wireshark that has parsing for this this
will be incompatible with the field generated by future sniffers, in
particular if we also have the HE-MU-other-user field included things
will get completely messed up.


Another way to solve this would be to include the HE-MU field twice in
the capture, but that's awkward to do in radiotap (extended presence
bitmaps etc.) and also it would duplicate some information and it
wouldn't be clear what to generate - so I don't think this is feasible.

The best way may be to declare this failed and just use a new bitmap
index, and have bit 24 just be empty in the future?


What do you think? Could wireshark do a point release of 2.6.x and 2.5.x
to include the changes? Or perhaps we could just say that 2.5.x would
just be broken for this, and people should upgrade for HE?

johannes

Re: [RFA] HE support

[Guy Harris]

On Apr 12, 2018, at 2:35 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> On Tue, 2018-01-30 at 09:25 +0100, Johannes Berg wrote:
>> 
>> http://www.radiotap.org/fields/HE-MU
> 
> Ugh, this yet again turned out to be incomplete - I missed that the RU
> stuff is duplicated for 160 MHz transmissions, so this can only capture
> one of the 80 MHz parts.
> 
> Probably the best way to solve this would be just change the field to
> the structure
> 
> u16 flags1
> u16 flags2
> u8  RU[8]
> 
> and then use up all the reserved bits for the needed known/center 26-
> tone bits (need an additional 6 bits, which we _just_ have).
> 
> However, this means that the wireshark that has parsing for this this
> will be incompatible with the field generated by future sniffers, in
> particular if we also have the HE-MU-other-user field included things
> will get completely messed up.
> 
> 
> Another way to solve this would be to include the HE-MU field twice in
> the capture, but that's awkward to do in radiotap (extended presence
> bitmaps etc.) and also it would duplicate some information and it
> wouldn't be clear what to generate - so I don't think this is feasible.
> 
> The best way may be to declare this failed and just use a new bitmap
> index, and have bit 24 just be empty in the future?
> 
> 
> What do you think? Could wireshark do a point release of 2.6.x and 2.5.x
> to include the changes? Or perhaps we could just say that 2.5.x would
> just be broken for this, and people should upgrade for HE?


n.{odd number}.x Wireshark releases are development releases; Gerald, is there any reason to care whether 2.5.x is broken when it tries to read this radiotap field?

2.6.0 is scheduled for April 18th; Gerald, if we have a finalized version of this radiotap field soon, would it be possible to get a change for that into the 2.6.0 release?

Re: [RFA] HE support

[Johannes Berg]

On Thu, 2018-04-12 at 02:54 -0700, Guy Harris wrote:
> 
> > What do you think? Could wireshark do a point release of 2.6.x and 2.5.x
> > to include the changes? Or perhaps we could just say that 2.5.x would
> > just be broken for this, and people should upgrade for HE?
> 
> 
> n.{odd number}.x Wireshark releases are development releases; Gerald,
> is there any reason to care whether 2.5.x is broken when it tries to
> read this radiotap field?

Ah, I wasn't aware of this, thanks.

> 2.6.0 is scheduled for April 18th; Gerald, if we have a finalized
> version of this radiotap field soon, would it be possible to get a
> change for that into the 2.6.0 release?

That's pretty soon, but another option would be to just #if 0 the broken
code quickly? That's a bit annoying, but better than shipping something
that we may have to break.

johannes

Re: [RFA] HE support

[Richard Sharpe]

On Thu, Apr 12, 2018 at 2:55 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Thu, 2018-04-12 at 02:54 -0700, Guy Harris wrote:
>>
>> > What do you think? Could wireshark do a point release of 2.6.x and 2.5.x
>> > to include the changes? Or perhaps we could just say that 2.5.x would
>> > just be broken for this, and people should upgrade for HE?
>>
>>
>> n.{odd number}.x Wireshark releases are development releases; Gerald,
>> is there any reason to care whether 2.5.x is broken when it tries to
>> read this radiotap field?
>
> Ah, I wasn't aware of this, thanks.
>
>> 2.6.0 is scheduled for April 18th; Gerald, if we have a finalized
>> version of this radiotap field soon, would it be possible to get a
>> change for that into the 2.6.0 release?
>
> That's pretty soon, but another option would be to just #if 0 the broken
> code quickly? That's a bit annoying, but better than shipping something
> that we may have to break.

I can go with either approach ... coding the changes will not take
long :-) Sigh. The perils of trying to stay at the front if the
charge.

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