mailing list archives
Re: Checksum filterable fields
From: Christopher Maynard <Christopher.Maynard () gtech com>
Date: Thu, 27 Jun 2013 19:36:10 +0000 (UTC)
<mmann78 () > writes:
Perhaps all checksum validations could be an enumeration of
"-1" (or "2"?) - unknown/disabled
"0" - good
"1" - bad
The TCP dissector does something similar for the window scaling factor. If
the 3-way handshake isn't captured, then the scaling factor is unknown and
set to -1. So, there is some precedence at indicating unknown values using
-1, and if changes are to be made, then -1 would be my vote.
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?
I like consistency, so it's fine by me. Just my 2 cents though.
Removing the bad_checksums does have at least 1 drawback though, and that's
that several of them are used in default coloring rules, so if they're
removed, users will likely end up with several warnings of the form:
Warn Could not compile color filter "Checksum Errors" from saved filters:
"<protocol>.checksum_bad" is neither a field nor a protocol name.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe