I have wondered before if a post-dissector could see skipped/overlapping fields and highlight them.
More likely, it could be an interesting project (for me, anyway) to play with a tool to:
- produce details of dissection (e.g. tshark -> PDML)
- walk the details of the fields, and look for discontinuities or overlaps in byte/bit coverage
- produce output that makes some kind of sense
- I expect there'll be some obvious types of exceptions that will need to be filtered out, but when I think about the kinds of bugs I make in my private quick-and-dirty dissectors, this kind of coverage checking would be useful to me
Martin
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.
I'd go with the plain name for the known fields and unknown/not set/... for the other case.
Just my 2 cents
Anders
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe