Coloring rules
A color is a saved display filter with a paint pot. It can point at a row, and it is not a verdict.
First match paints the row
Coloring rules live under View, then Coloring Rules. Each rule is a display filter plus a foreground and a background. Wireshark walks the list from top to bottom and paints a row with the first rule that matches. A broad rule above a specific one hides the specific one. Order is the whole mechanism.
The default rules already paint some TCP analysis notes, routing protocols, and a few application protocols. Read them once in the lab profile before you trust a color. A black or red row often means “a TCP analysis flag fired,” which is a lead. The flag still has to be read in the details tree.
Color a conversation while you work
Right-click a row and colorize that conversation if you want a temporary mark while you scroll. That paint follows the conversation across the file and clears when you clear conversation colors. It is a reading aid for one sitting. It is not saved as the reason for a finding.
A rule you want every time belongs in the lab profile: retransmissions, zero windows, DNS errors, or HTTP requests to the lab server. Keep the list short. A profile that paints everything stops painting anything your eye can use.
Worked case: make retransmissions visible, then read them
The lab file of a file copy to 10.8.0.20 feels slow. You add one rule at the top of the lab profile: name it TCP retransmit, filter tcp.analysis.retransmission, and give it a color you do not use for anything else. Apply. Scattered rows light up during the copy and nowhere else.
Click one painted row. The details tree says this frame is a suspected retransmission, and it points at the earlier frame it repeats. You now have a time and a stream index. The color did its job by making the row findable. The note you write quotes tcp.analysis.retransmission and the frame numbers, so the finding still stands if someone opens the file with the default colors.
tcp.analysis.retransmission
What a color must not do
Do not stack a rule whose filter you have not tested. A typo in a coloring rule fails closed or paints the wrong rows, and a painted row feels more certain than a filter box does. Put the filter in the display-filter box first, confirm the rows, then paste that same text into the rule.
Exporting a screenshot of colored rows is a poor handoff. The filter string is the handoff. Anyone can apply it, in Wireshark or in tshark, and land on the same frames.
Diagram
From a filter you trust to a color that only helps you find it
- Filter
Type the display filter and confirm the rows are the ones you mean.
tcp.analysis.retransmission
- Rule
Add a coloring rule with that exact filter. Put specific rules above broad ones.
- Row
A painted row is a place to click. Open the field that made the rule match.
- Note
Record the filter and the frame numbers. The color stays in your profile.
Check yourself
1. Two rules match the same row. Which one paints it?
2. You want retransmissions painted in the lab profile. What do you do before saving the rule?
3. A teammate does not see your colors. What do you send so they can find the same rows?