On Tue, Jun 21, 2022 at 9:53 AM Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
>
> Hi folks,
>
> One of the things I dislike in dissectors is where people don't
> dissect all the bytes in a packet. Sometimes it is done because the
> bytes are padding bytes or because the function of those bytes is
> unknown or what have you.
>
> An interesting case relates to radiotap where since the HE (High
> Efficiency, Wi-Fi 6) version the spec has included an set of 'known'
> fields in the header. These bits indicate which of the following
> fields are actually known. Fields that are not known will have values
> in them but the values did not come from hardware.
>
> The question is: Should those fields be displayed but marked as not
> known? That is, should they be inserted into the tree.
>
> Doing so makes filtering easier because you can just filter on the
> fields of interest instead of having to filter on a known field.
>
> Not doing so leaves gaps in the data if you are looking at the data
> portion of a frame.
>
> Any thoughts on how this should be handled?
I have thought of an approach that allows me to insert all the fields
while at the same time allowing filtering on the know fields or
unknown fields (and I can imagine someone wanting to filter on unknown
fields to determine whether they have zeros or garbage in them.
For the known fields, have a header field with a filter string with
just the name. Eg, "radiotap.eht.primary_80_mhz_channel_position", but
another header field for the unknown case with the filter string
"radiotap.eht.primary_80_mhz_channel_position_not_known". It requires
a bit of extra work but conforms to the philosophy of dissecting all
fields while allowing users to search on fields of interest.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)