There has been discussion over the years about standardizing the way checksums are handled in Wireshark. A lot of the discussion has been captured in bug 8859 [1], and I started writing a patch that would address it [2].
In developing the patch, I came across the following types of checksum "behavior"
1. Just dissect checksum field in protocol. No attempt at verification.
2. Checksum validated, only "bad" checksum noted with <protocol>.checksum_bad display filter and/or expert_info
3. Checksum validated, both good and bad checksums noted with their own display filters. "Bad" checksum may have expert info too.
4. All of #3 above, but with a preference to disable validation, so both good and bad filters end up false (which can be construed as confusing, see bugs 10620 [3] and 12058 [4])
5. Similar to #4 above, but with the protocol option of not having the checksum present in the packet (based on some flags in packet or whatever)
The new API proto_tree_add_checksum from the patch tries to address all of these types of behavior. The currently proposed solution does so with 3 parameters - a hf_ parameter for the checksum itself, an (optional) hf_ parameter for the checksum "status", and an (optional) expert info that would get called for mismatched checksums (when asked to validate). The "optional" parameters are optional now just so I didn't have to create all of the necessary fields and expert info for dissectors that didn't already have them (that can be done later).
The "status" display filter would be provided by the dissector with a "standard" value_string (and a "standard" filter field format like "<protocol>.checksum.status" that could enumerate all of the potential scenarios outlined above (and maybe a few others that pop up later). These would be:
Bad (0) Validated checksum mismatch
Good (1) Validated checksum match
Unverified (2) Checksum not validated (because of a dissector preference or because dissector never tried to validate)
Not present (3) Checksum not present in packet. Checksum hf_ field value = 0.
Now the problem comes in when dissectors are converted to use this new API and they lose their (well known) "good" and "bad" filters. The "good" and "bad" filters are used on "popular" protocols like IP, TCP, UDP, ICMP so that's probably where we'd get the most complaints from users. However, I still feel the change is worth it to get the standardization.
Another option would be to expand the dissectors that don't have "good" and "bad" filters to do so, then that can become the standard. Requires the creation of a lot more filters, but I'm still hung up on it because it doesn't clear up the problem of "how do I know good and bad from 'unverified'?" (the issue of bug 12058).
João and I have gone back and forth on this issue within the patch, so I thought I'd open it up to other opinions.
