On May 28, 2018, at 9:29 AM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
> This is in relation to the radiotap headers for HE and HE-MU (and more).
"More" as in MCS, VHT, HE-MU-other-user, HE-MU, and HE, all of which have "known" flags.
> The issue is that there are fields in those headers that are unknown
> unless the appropriate known bit is set to true elsewhere in the
> header.
>
> The approach I took initially was to have two header types:
>
> 1. One for when the field was known, and
> 2. One for when the field was unknown where the search string had unknown in it
>
> I would then use the appropriate HF in the code.
>
> However, people have complained that this is weird.
>
> My thinking was:
>
> 1. I don't like it when fields are not dissected, and
> 2. By using a different search string when a field is unknown we would
> not get false positives (usually the field is 0, but 0 is usually also
> a valid value wen the field is known.)
>
> An alternative is to change the label associated with the field to
> include the word unknown,
This is unwise.
A given named field shouldn't change its properties over time.
Don't do that.
Perhaps there should be a "not present in this packet" flag in the flags field of a field_info structure, which could be set in these cases. There might be other places where the bytes/bits for a given field are always present in the packet, but are not used unless the "XXX is present" flag is set elsewhere in the packet.
(Perhaps there should also be a "the bits of this field do not constitute a valid value in the encoding used for the field" flag, to use with, for example, invalid strings in the character encoding of a string.)