From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: [RFA] HE support Date: Thu, 12 Apr 2018 11:35:07 +0200 Message-ID: <1523525707.12930.6.camel@sipsolutions.net> References: <1517300719.2189.51.camel@sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1517300719.2189.51.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org List-Unsubscribe: To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org Cc: Richard Sharpe List-Id: radiotap@radiotap.org 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