RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org,
	Richard Sharpe
	<realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Gerald Combs <gerald-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Subject: Re: [RFA] HE support
Date: Thu, 12 Apr 2018 02:54:12 -0700
Message-ID: <9FE36B35-5238-436D-9B5A-342C92D20701@alum.mit.edu> (raw)
In-Reply-To: <1523525707.12930.6.camel-cdvu00un1VgdHxzADdlk8Q@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?

  parent reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30  8:25 Johannes Berg
     [not found] ` <1517300719.2189.51.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-02-20  9:37   ` Johannes Berg
     [not found]     ` <1519119420.16723.26.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-02-20 13:01       ` Johannes Berg
     [not found]         ` <1519131691.16723.35.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-02-20 14:59           ` Richard Sharpe
     [not found]             ` <CACyXjPxQLN3iiCjVu5X5ZQUMGBEY9FyM9dnPmEiT7XQnaUhjEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-20 15:06               ` Johannes Berg
2018-02-20 16:05       ` Richard Sharpe
2018-02-20 16:42   ` Johannes Berg
     [not found]     ` <1519144938.16723.42.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-02-22 11:13       ` Johannes Berg
2018-04-12  9:35   ` Johannes Berg
     [not found]     ` <1523525707.12930.6.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-04-12  9:54       ` Guy Harris [this message]
     [not found]         ` <9FE36B35-5238-436D-9B5A-342C92D20701-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-04-12  9:55           ` Johannes Berg
     [not found]             ` <1523526947.12930.8.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-04-12 13:56               ` Richard Sharpe

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9FE36B35-5238-436D-9B5A-342C92D20701@alum.mit.edu \
    --to=guy-frubxkncsvf2fbvcvol8/a@public.gmane.org \
    --cc=gerald-IZ8446WsY0/dtAWm4Da02A@public.gmane.org \
    --cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
    --cc=realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git