Re: [RFA] HE support

[Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]

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?