* 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
[parent not found: <1486992211.19813.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <D96F5F50-5B44-487C-8FF8-36A793960B7D-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* 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
[parent not found: <1487014748.19813.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <0FB8C34C-910C-404F-97BA-18BB7F8949C4-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* 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
[parent not found: <1487015370.19813.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <4443A151-EFD0-44A4-A892-C40218EE0291-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* 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] ` <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] ` <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] ` <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] ` <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
[parent not found: <1487162908.31885.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <1487764486.2215.5.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <1488266885.2388.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <1504859711.6177.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <1508932475.2421.34.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]
* 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
[parent not found: <CAF7Mx6qFmbyDex8VOV9sxbMXofQVk9dpzBQNK0S57GCTfbw_PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* 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).