This is a static archive of our old Q&A Site. Please post any new questions and answers at

Getting Colorfilter error after upgrading to 2.2.0


After I upgraded to 2.2.0, I now get the following error in the Wireshark debug console when selecting one of my configuration profiles. My profiles did not change, and never had an issue with any earlier version.

Has anyone else had this issue?

21:15:40 Warn Could not compile "Checksum Errors" in colorfilters file "C:\Dropbox\PROFILES-SETTINGS-SOURCEDATA\Wireshark\PersonalConfiguration\profiles\VoIP - SIP\colorfilters". eth.fcs_bad (type=Label) cannot participate in '==' comparison.

asked 12 Sep '16, 19:25

Rooster_50's gravatar image

accept rate: 15%

One Answer:


As indicated in the release notes, the format for the checksum coloring rules was changed:

proto_tree_add_checksum was added as an API. This attempts to standardize how checksums are reported and filtered for within *Shark. There are no more individual "good" and "bad" filter fields, protocols now have a "checksum.status" field that records "Good", "Bad" and "Unverified" (neither good or bad). Color filters provided with Wireshark have been adjusted to the new display filter names, but custom ones may need to be updated.

So you need to update your profile accordingly.

answered 12 Sep '16, 22:52

Pascal%20Quantin's gravatar image

Pascal Quantin
accept rate: 30%

This practically means to go through your colorization rules in that profile (file cfilters in the profile directory) using a text editor, search for eth.cfs_bad in it, and update the affected part of the failing rule(s) from old eth.fcs_bad == true to !(eth.fcs.status == Good) or another one better suiting your needs.

(12 Sep '16, 22:57) sindy

A checksum status, such as eth.fcs.status, can have one of four values:

  • "Good" - this means the checksum was checked and it's correct;
  • "Bad" - this means the checksum was checked and it's not correct;
  • "Unverified" - this means the checksum was present, but wasn't checked (for example, because not all the data the checksum covers was captured, so it's impossible to check it);
  • "Not present" - this means the checksum field was present, but has a special value meaning "no checksum" - 0 is used in some protocols to mean "no checksum was computed for this packet, so there's no checksum check to be done").

So if you want to flag all packets with a bad checksum with a particular color, the filter expression would be something such as eth.fcs.status == "Bad".

(13 Sep '16, 01:49) Guy Harris ♦♦

Thank you to Pascal, sindy, and Guy for all of your help. I finally got all of my profiles cleaned up and working now. Thanks again!

(13 Sep '16, 22:34) Rooster_50