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.