Wireshark-dev: Re: [Wireshark-dev] Writing a wtap module for CommView WLAN Analyzer and Decoder
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 19 Apr 2021 15:45:08 -0700
On Apr 19, 2021, at 10:02 AM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:

> On Sun, Apr 18, 2021 at 9:30 PM Guy Harris <gharris@xxxxxxxxx> wrote:
> 
>> We may want to change the 802.11 pseudo-header to have data rates in units of 100 Kb/s rather than 500 Kb/s, to handle NCFX and possibly other files.  (We might also want to add support for "scaled integer" fields, which display not as the raw value but as the value multiplied by/divided by a scaling factor, if avoiding inaccuracies due to scaling values not being representable exactly as floating-point binary numbers (.5 can, .1 can't).
> 
> I think the problem will be that the radiotap HE and other headers
> support much more info than what you have suggested.

That suggestion was a specific change to deal with a particular problem, not a suggestion intended to handle all future issues.  The pseudo-header should be expanded to include whatever is needed for all forms of 802.11 metadata.

> Will we also add things like GI, LFT symbol size, # LTF symbols, Pre
> FEC padding, etc, to the pseudo-header?

Yes, we should.

> In addition, radiotap now supports TLVs (since they ran out of bits in
> the features word). However, that is possibly easier to handle, since
> an unknown TLV can simply be displayed as raw bytes.

Yes, the idea was originally that, for any newly-added field, there is:

	code that doesn't understand the newly-added field, in which case it presumably won't understand fields added after the newly-added field, so it's OK to stop parsing at the last field the code *does* understand;

	code that does understand the newly-added field, in which case it can parse it, and stop if it runs across a field it doesn't understand.

Any code that handles TLVs also needs to handle all the fields added prior to the addition of TLVs.

There's also a provision for vendor-specific fields in radiotap.  We might need a mechanism to allow dissectors to register to handle either radiotap TLVs or vendor-specific fields.