radiotap.netbsd.org archive mirror
 help / color / mirror / Atom feed
* HE (11ax) extensions
@ 2017-02-13 13:23 Johannes Berg
       [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-13 13:23 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

Hi,

We're looking to add HE/11ax extensions to radiotap.

Has anyone else already identified the data that would be necessary?

So far I have - assuming 'presence bits' for each,

for HE_SU:
 * beam change (1 bit)
 * UL/DL (1 bit)
 * MCS (4 bits)
 * DCM (1 bit)
 * BSS color (6 bits)
 * spatial reuse (TBD)
 * bandwidth
 * GI+LTF size (2 bits)
 * Nsts
 * TXOP duration (7 bits)
 * Coding (BCC/LDPC)
 * LDPC extra symbol flag
 * STBC flag
 * TX BF flag
 * pre-FEC padding factor
 * PE disambiguity
 * doppler mode

for HE_MU:
 * UL/DL
 * MCS
 * DCM
 * BSS color
 * spatial reuse
 * TXOP Duration
 * bandwidth
 * # of HE SIGB symbols
 * SIG-B compression
 * GI+LTF size
 * # of HE-LTF symbols
 * LDPC extra symbol flag
 * STBC
 * pre-FEC padding factor
 * PE disambiguity
 * doppler mode
 * RU allocation
 * center 26 tone RU
 * per-user: STA-ID, Nsts, TX BF, MCS, DCM, Coding

for HE_TRIG:
(similar to HE_SU but a little restricted)


Obviously a number of these fields are in all three formats, and I
haven't really done a full size analysis, but perhaps we should split
the extra MU fields into a separate bit so that they don't have to have
space allocated to them when not used, for SU/TRIG formats?

johannes

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

* Re: HE (11ax) extensions
       [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-02-13 19:33   ` Simon Barber
       [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2017-02-15 12:48   ` Johannes Berg
  2017-09-08  8:35   ` Johannes Berg
  2 siblings, 1 reply; 19+ messages in thread
From: Simon Barber @ 2017-02-13 19:33 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

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

For HT and VHT one of the things that is missing is the total length of aggregates (including padding) - it’s in the L-SIG header, would be nice to have it exposed (since most chipsets pass up everything that’s in the header). I assume the same will be true for ax. Also some standardized way to put aggregates back together. My latest wireshark extension uses same TSF as that clue. See https://code.wireshark.org/review/#/c/20043/ <https://code.wireshark.org/review/#/c/20043/>

Simon

> On Feb 13, 2017, at 5:23 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> Hi,
> 
> We're looking to add HE/11ax extensions to radiotap.
> 
> Has anyone else already identified the data that would be necessary?
> 
> So far I have - assuming 'presence bits' for each,
> 
> for HE_SU:
> * beam change (1 bit)
> * UL/DL (1 bit)
> * MCS (4 bits)
> * DCM (1 bit)
> * BSS color (6 bits)
> * spatial reuse (TBD)
> * bandwidth
> * GI+LTF size (2 bits)
> * Nsts
> * TXOP duration (7 bits)
> * Coding (BCC/LDPC)
> * LDPC extra symbol flag
> * STBC flag
> * TX BF flag
> * pre-FEC padding factor
> * PE disambiguity
> * doppler mode
> 
> for HE_MU:
> * UL/DL
> * MCS
> * DCM
> * BSS color
> * spatial reuse
> * TXOP Duration
> * bandwidth
> * # of HE SIGB symbols
> * SIG-B compression
> * GI+LTF size
> * # of HE-LTF symbols
> * LDPC extra symbol flag
> * STBC
> * pre-FEC padding factor
> * PE disambiguity
> * doppler mode
> * RU allocation
> * center 26 tone RU
> * per-user: STA-ID, Nsts, TX BF, MCS, DCM, Coding
> 
> for HE_TRIG:
> (similar to HE_SU but a little restricted)
> 
> 
> Obviously a number of these fields are in all three formats, and I
> haven't really done a full size analysis, but perhaps we should split
> the extra MU fields into a separate bit so that they don't have to have
> space allocated to them when not used, for SU/TRIG formats?
> 
> johannes


[-- Attachment #2: Type: text/html, Size: 3073 bytes --]

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

* Re: HE (11ax) extensions
       [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
@ 2017-02-13 19:39       ` Johannes Berg
       [not found]         ` <1487014748.19813.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2017-02-13 19:40       ` Johannes Berg
  2017-02-15  9:05       ` Johannes Berg
  2 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-13 19:39 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header, would
> be nice to have it exposed (since most chipsets pass up everything
> that’s in the header).

I don't know about "most", but I know ours doesn't :-)

> Also some standardized way to put aggregates back together. My latest
> wireshark extension uses same TSF as that clue.
> See https://code.wireshark.org/review/#/c/20043/

We already have that, in the A-MPDU status field there's a reference
number that's supposed to be constant within the same A-MPDU and change
between consecutive A-MPDUs.

johannes

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

* Re: HE (11ax) extensions
       [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2017-02-13 19:39       ` Johannes Berg
@ 2017-02-13 19:40       ` Johannes Berg
  2017-02-15  9:05       ` Johannes Berg
  2 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-02-13 19:40 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header

It is, btw, very tempting to define fields for the various headers like
L-SIG, SIG-A, SIG-B etc, but most chipsets won't be able to report
everything there so we'd have to support masks, and we generally don't
support anything with variable length.

johannes

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

* Re: HE (11ax) extensions
       [not found]         ` <1487014748.19813.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-02-13 19:42           ` Simon Barber
       [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Simon Barber @ 2017-02-13 19:42 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

It’s not correctly implemented on captures from Macs - it increments for every MPDU. TSF is reliable on all platforms that I’ve seen, although has different reference points for different platforms.

One things that is very odd is the different parameters for MU - 4 sets, but I’ve only ever seen 1 MPDU reported. How is this supposed to be used?

Simon

> On Feb 13, 2017, at 11:39 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
>> For HT and VHT one of the things that is missing is the total length
>> of aggregates (including padding) - it’s in the L-SIG header, would
>> be nice to have it exposed (since most chipsets pass up everything
>> that’s in the header).
> 
> I don't know about "most", but I know ours doesn't :-)
> 
>> Also some standardized way to put aggregates back together. My latest
>> wireshark extension uses same TSF as that clue.
>> See https://code.wireshark.org/review/#/c/20043/
> 
> We already have that, in the A-MPDU status field there's a reference
> number that's supposed to be constant within the same A-MPDU and change
> between consecutive A-MPDUs.
> 
> johannes

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

* Re: HE (11ax) extensions
       [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
@ 2017-02-13 19:49               ` Johannes Berg
       [not found]                 ` <1487015370.19813.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2017-02-15  8:58               ` Johannes Berg
  2017-02-15  9:08               ` Guy Harris
  2 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-13 19:49 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
> It’s not correctly implemented on captures from Macs - it increments
> for every MPDU. TSF is reliable on all platforms that I’ve seen,
> although has different reference points for different platforms.
> 
> One things that is very odd is the different parameters for MU - 4
> sets, but I’ve only ever seen 1 MPDU reported. How is this supposed
> to be used?

I don't think it *can* be used by a real sniffer, unless it is somehow
able to decode for multiple users at once?

johannes

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

* Re: HE (11ax) extensions
       [not found]                 ` <1487015370.19813.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-02-13 20:08                   ` Simon Barber
       [not found]                     ` <4443A151-EFD0-44A4-A892-C40218EE0291-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Simon Barber @ 2017-02-13 20:08 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

And even then, where would the multiple MPDUs go, and how would they be delimited? If this option is unused, and unusable, and it causes big issues with UI, then could it be deprecated? (say only the first set of parameters are valid, all others are unused?)

Simon

> On Feb 13, 2017, at 11:49 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
>> It’s not correctly implemented on captures from Macs - it increments
>> for every MPDU. TSF is reliable on all platforms that I’ve seen,
>> although has different reference points for different platforms.
>> 
>> One things that is very odd is the different parameters for MU - 4
>> sets, but I’ve only ever seen 1 MPDU reported. How is this supposed
>> to be used?
> 
> I don't think it *can* be used by a real sniffer, unless it is somehow
> able to decode for multiple users at once?
> 
> johannes

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

* Re: HE (11ax) extensions
       [not found]                     ` <4443A151-EFD0-44A4-A892-C40218EE0291-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
@ 2017-02-13 20:14                       ` Johannes Berg
  0 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-02-13 20:14 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 12:08 -0800, Simon Barber wrote:
> And even then, where would the multiple MPDUs go, and how would they
> be delimited? 

That's a good point. Perhaps it was intended to convey some sort of
half-decoding? I frankly don't remember any discussions about this.

> If this option is unused, and unusable, and it causes big issues with
> UI, then could it be deprecated? (say only the first set of
> parameters are valid, all others are unused?)

Does it cause problems in any UI? wireshark just displays all the
fields, so it shouldn't really cause any problems.

Anyway, this has certainly never been generated on Linux, and probably
not elsewhere, so I have no objection to deprecating it and marking
those fields reserved or so.

johannes

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

* Re: HE (11ax) extensions
       [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2017-02-13 19:49               ` Johannes Berg
@ 2017-02-15  8:58               ` Johannes Berg
  2017-02-15  9:08               ` Guy Harris
  2 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-02-15  8:58 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
> It’s not correctly implemented on captures from Macs - it increments
> for every MPDU. TSF is reliable on all platforms that I’ve seen,
> although has different reference points for different platforms.

On this point, btw, you should probably just tell somebody to fix it :)

We can add all the standard ways we want to, but if people don't use
them correctly there's not much we can do about it. I don't want to add
yet another standard way to do this, just to have the next guy use it
wrong ...

johannes

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

* Re: HE (11ax) extensions
       [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2017-02-13 19:39       ` Johannes Berg
  2017-02-13 19:40       ` Johannes Berg
@ 2017-02-15  9:05       ` Johannes Berg
  2 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-02-15  9:05 UTC (permalink / raw)
  To: Simon Barber; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header, would
> be nice to have it exposed (since most chipsets pass up everything
> that’s in the header).

Come to think of this - that really should have been part of the A-MPDU 
field, but I don't think it makes sense to put it into an HE extension
either, so it'd probably be better as a separate field.

johannes

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

* Re: HE (11ax) extensions
       [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2017-02-13 19:49               ` Johannes Berg
  2017-02-15  8:58               ` Johannes Berg
@ 2017-02-15  9:08               ` Guy Harris
  2 siblings, 0 replies; 19+ messages in thread
From: Guy Harris @ 2017-02-15  9:08 UTC (permalink / raw)
  To: Simon Barber; +Cc: Johannes Berg, radiotap-S783fYmB3Ccdnm+yROfE0A

On Feb 13, 2017, at 11:42 AM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:

> It’s not correctly implemented on captures from Macs - it increments for every MPDU.

bugreport.apple.com is your friend (well, it'll be all of our friends again once they fix the damn redirect loop).  You'll need to get an Apple developer account in order to file bugs.  (Note: the more duplicates a bug has, the more attention is paid to it.)

The spec says

	The reference number is generated by the capture device and is the same across each subframe of an A-MPDU. Since the capture device might be capable of capturing multiple channels or data from multiple (concurrent) captures could be merged, the reference number is not guaranteed to be unique across different channels. As a result, applications should use the channel information together with the reference number to identify the subframes belonging to the same A-MPDU.

So are you saying that it increments for each *subframe* in macOS?

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

* Re: HE (11ax) extensions
       [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2017-02-13 19:33   ` Simon Barber
@ 2017-02-15 12:48   ` Johannes Berg
       [not found]     ` <1487162908.31885.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2017-09-08  8:35   ` Johannes Berg
  2 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-15 12:48 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2017-02-13 at 14:23 +0100, Johannes Berg wrote:
> Hi,
> 
> We're looking to add HE/11ax extensions to radiotap.

I looked more, and decided that it didn't really make a lot of sense to
parse it all and put it back together ... so instead, how about we just
put SIG-A1/A2/B common/B multiuser in?

Something like

http://www.radiotap.org/fields/HE

but I'm not really sure
* if sig_B_user[1] should be in HE or in HE multiuser
* if 3 bits are really needed for the Center 26-tone RU field, I'm not
sure how it could be non-present

Does this make sense?

johannes

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

* Re: HE (11ax) extensions
       [not found]     ` <1487162908.31885.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-02-22 11:54       ` Johannes Berg
       [not found]         ` <1487764486.2215.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-22 11:54 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

> Something like
> 
> http://www.radiotap.org/fields/HE
> 
> but I'm not really sure
> * if sig_B_user[1] should be in HE or in HE multiuser
> * if 3 bits are really needed for the Center 26-tone RU field, I'm
> not sure how it could be non-present

It really can be non-present, obviously SIG-B common field is already
variable length :)

Anyway, that proposal missed a number of things and didn't really make
any sense, here's a new one:

http://www.radiotap.org/fields/HE
http://www.radiotap.org/fields/HE-MU-common
http://www.radiotap.org/fields/HE-MU-user

One thing I like less about this is that the bitrate of the MPDU will
be recorded in the "HE" field for SU/trigger-based PPDUs, but in the
"HE-MU-user" field for MU PPDUs. But since all the data is present, I
guess that's actually fine.

johannes

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

* Re: HE (11ax) extensions
       [not found]         ` <1487764486.2215.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-02-28  7:28           ` Johannes Berg
       [not found]             ` <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-02-28  7:28 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Wed, 2017-02-22 at 12:54 +0100, Johannes Berg wrote:
> > 
> Anyway, that proposal missed a number of things and didn't really
> make any sense, here's a new one:
> 
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU-common
> http://www.radiotap.org/fields/HE-MU-user

FWIW, I've not pursued this further for now since the spec is still a
moving target. I'm told HE-SIG-B is fairly stable, but HE-SIG-A is
still a heavily contended topic (at least some parts of it)

johannes

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

* Re: HE (11ax) extensions
       [not found]             ` <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-06-27 13:41               ` Johannes Berg
  0 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-06-27 13:41 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Tue, 2017-02-28 at 08:28 +0100, Johannes Berg wrote:
> On Wed, 2017-02-22 at 12:54 +0100, Johannes Berg wrote:
> > > 
> > 
> > Anyway, that proposal missed a number of things and didn't really
> > make any sense, here's a new one:
> > 
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU-common
> > http://www.radiotap.org/fields/HE-MU-user
> 
> FWIW, I've not pursued this further for now since the spec is still a
> moving target. I'm told HE-SIG-B is fairly stable, but HE-SIG-A is
> still a heavily contended topic (at least some parts of it)

In the meantime, I've come to the conclusion that it's a stupid idea to
encode the data like in HE-SIG-A, for multiple reasons:

1) the encoding heavily depends on the PPDU type (SU, ER SU, MU, TB),
and there's practically nothing common between them - this means
decoding has lots of special cases

2) the encoding is really really tight on bits, doing tricks like
DCM=STBC=1 to indicate a 5th possibility for the 2-bit LTF+GI field,
this also makes it awkward to decode again in tools like wireshark

3) TB PPDUs don't even contain the necessary rate data, it's given by
the trigger frame, so one would have to correlate that during encoding.
For pure sniffer mode, that may be necessary, but for some "monitor
while operating" modes, the real rate etc. would be available

(and there are probably more reasons)

I'm going on sabbatical soon, but I'll revisit this in September or
later to come up with a better proposal.

johannes

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

* Re: HE (11ax) extensions
       [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2017-02-13 19:33   ` Simon Barber
  2017-02-15 12:48   ` Johannes Berg
@ 2017-09-08  8:35   ` Johannes Berg
       [not found]     ` <1504859711.6177.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-09-08  8:35 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

Hi all,

I've updated my HE proposal:

http://www.radiotap.org/fields/HE
http://www.radiotap.org/fields/HE-MU
http://www.radiotap.org/fields/HE-MU-user

This now basically just requires the HE field even for MU
transmissions, with the HE-MU field giving some more detail of those;
the HE-MU-user is just for completeness so one can capture the SIG-B
for multiple users even if the frame isn't captured.

I'll still wait for the spec to settle down more until formally
proposing this, but feedback is very welcome.

johannes

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

* Re: HE (11ax) extensions
       [not found]     ` <1504859711.6177.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-10-25 11:54       ` Johannes Berg
       [not found]         ` <1508932475.2421.34.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Johannes Berg @ 2017-10-25 11:54 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> Hi all,
> 
> I've updated my HE proposal:
> 
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU
> http://www.radiotap.org/fields/HE-MU-user

And again, for D2.0

johannes

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

* Re: HE (11ax) extensions
       [not found]         ` <1508932475.2421.34.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2017-10-25 12:17           ` Arend Van Spriel
       [not found]             ` <CAF7Mx6qFmbyDex8VOV9sxbMXofQVk9dpzBQNK0S57GCTfbw_PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 19+ messages in thread
From: Arend Van Spriel @ 2017-10-25 12:17 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

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

Op 25 okt. 2017 13:54 schreef "Johannes Berg" <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
>
> On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> > Hi all,
> >
> > I've updated my HE proposal:
> >
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU
> > http://www.radiotap.org/fields/HE-MU-user

The last link doesn't work (for me?).

Regards,
Arend

> And again, for D2.0
>
> johannes

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

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

* Re: HE (11ax) extensions
       [not found]             ` <CAF7Mx6qFmbyDex8VOV9sxbMXofQVk9dpzBQNK0S57GCTfbw_PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-10-25 12:18               ` Johannes Berg
  0 siblings, 0 replies; 19+ messages in thread
From: Johannes Berg @ 2017-10-25 12:18 UTC (permalink / raw)
  To: Arend Van Spriel; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Wed, 2017-10-25 at 14:17 +0200, Arend Van Spriel wrote:
> Op 25 okt. 2017 13:54 schreef "Johannes Berg" <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> >
> > On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> > > Hi all,
> > >
> > > I've updated my HE proposal:
> > >
> > > http://www.radiotap.org/fields/HE
> > > http://www.radiotap.org/fields/HE-MU
> > > http://www.radiotap.org/fields/HE-MU-user
> The last link doesn't work (for me?).

Indeed, it should be

http://www.radiotap.org/fields/HE-MU-other-user

I also notice that github hasn't updated the HE page with the data6
part of the field yet.

johannes

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

end of thread, other threads:[~2017-10-25 12:18 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-13 13:23 HE (11ax) extensions Johannes Berg
     [not found] ` <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 19:33   ` Simon Barber
     [not found]     ` <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 19:39       ` Johannes Berg
     [not found]         ` <1487014748.19813.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 19:42           ` Simon Barber
     [not found]             ` <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 19:49               ` Johannes Berg
     [not found]                 ` <1487015370.19813.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-13 20:08                   ` Simon Barber
     [not found]                     ` <4443A151-EFD0-44A4-A892-C40218EE0291-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2017-02-13 20:14                       ` Johannes Berg
2017-02-15  8:58               ` Johannes Berg
2017-02-15  9:08               ` Guy Harris
2017-02-13 19:40       ` Johannes Berg
2017-02-15  9:05       ` Johannes Berg
2017-02-15 12:48   ` Johannes Berg
     [not found]     ` <1487162908.31885.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-22 11:54       ` Johannes Berg
     [not found]         ` <1487764486.2215.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-02-28  7:28           ` Johannes Berg
     [not found]             ` <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-06-27 13:41               ` Johannes Berg
2017-09-08  8:35   ` Johannes Berg
     [not found]     ` <1504859711.6177.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-10-25 11:54       ` Johannes Berg
     [not found]         ` <1508932475.2421.34.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-10-25 12:17           ` Arend Van Spriel
     [not found]             ` <CAF7Mx6qFmbyDex8VOV9sxbMXofQVk9dpzBQNK0S57GCTfbw_PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-25 12:18               ` 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).