<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. :)
