While I thought <dissector>.good_checksum = FALSE and <dissector>.bad_checksum = TRUE, was duplicative, you provided a valid case for having it.
Perhaps all checksum validations could be an enumeration of
"-1" (or "2"?) - unknown/disabled
"0" - good
"1" - bad
If we're already going to take a hit with changed display filter names in the name of consistency, why not go all the way?
The "more duplicative" case is with bad_checksum field and expert info (because presumably only bad checksums are expert_info worthy). When I converted some of the expert info to the new API, I felt stuck with
<dissector>.bad_checksum (FT_BOOLEAN field for dissection)
<dissector>.bad_checksum.expert (FT_NONE field for expert info)
I thought FT_BOOLEAN and FT_NONE would cause issues because they are incompatible field types, so the filter names couldn't be shared.
If checksum validation is disabled, then dissector checksum validator field would get -1 (or 2), and no expert info would be generated.
-----Original Message-----
From: Christopher Maynard <Christopher.Maynard@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thu, Jun 27, 2013 10:26 am
Subject: Re: [Wireshark-dev] Checksum filterable fields
<mmann78@...> writes:
> The ones that really seem excessive are 5 & 6 - do we really need this
duplication? <dissector>.bad_checksum = TRUE equals
<dissector>.good_checksum = FALSE. Could we consolidate all (that have
checksum verification) to
>
> Checksum field + "good" boolean field filter (of the form
<dissector>.good_checksum) + expert_info for bad checksum (of the form
<dissector>.bad_checksum)
So in this case, if one wanted to filter for bad checksums, then s/he would
have to use "good_checksum == 0", as opposed to "bad_checksum == 1". Seems
reasonable to me.
What do you propose for those checksums where checksum verification can be
disabled? I think in those cases you would still need both good_checkum and
bad_checksum because when checksum verification is disabled, both are set to
FALSE, since it's unknown whether the checksum is good or bad, so you
couldn't necessarily assume that just because "good_checksum == 0" that the
checksum is actually bad. For those, you'd need, bad_checksum == 1" for
finding packets with bad checksums, and "good_checksum == 1" for finding
packets with good checksums. So when checksum verification is disabled,
should #6 be used here with an expert info for "unknown", or maybe just #5
is good enough?
Of course given that some checksum validations can be disabled, it might be
confusing as to why some checksums have a bad_checksum display filter (those
whose checksum validations can be disabled) and some don't have a
bad_checksum display filter (those that always validate their checksums).
So in the end, I'm not sure what the best solution is. Glad I could be so
unhelpful. :)
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
