How do Wireshark coloring rules use display filters, and why can a `udp` rule above a `dns` rule stop DNS packets getting the DNS color?
answer
- same filter language
- highlight, never hide
- rules checked top to bottom
- first match wins
- frame.coloring_rule.name
basics
~20 sEach Wireshark coloring rule is a name, a display filter and colors; a row takes the colors of the first rule whose filter matches. DNS usually rides on UDP, so a udp rule above a dns rule claims those packets.
solid answer
~40 sA coloring rule pairs a name with a display filter and a foreground and background color, and View > Coloring Rules lists them in order. For each packet the rules are tried top to bottom and the first match wins, so specific rules belong above general ones: with `udp` above `dns`, DNS over UDP takes the UDP color. Coloring highlights, it never hides: a rule such as `http.response.code >= 500` paints failures in a chosen color while the surrounding traffic stays in view, which a display filter cannot do. The rule that fired is recorded in each packet it colored as `frame.coloring_rule.name` and `frame.coloring_rule.string`, so you can filter on it. Permanent rules are saved in the profile's `colorfilters` file; temporary ones from Colorize Conversation's Color 1-10 entries last until Wireshark quits.
go deeper
Recall that coloring rules are display filters with colors, that they never hide packets, and that the first matching rule colors the row.
Explain how rule order decides the color, and how frame.coloring_rule.name shows which rule fired on a packet.
Build a small, ordered rule set that makes failures stand out in context during an incident, and debug a rule that another rule shadows.
Decide whether a team keeps a shared analysis profile with agreed coloring rules, and who maintains it as the services change.
## A coloring rule is a display filter with colors Wireshark colors rows in the packet list according to **coloring rules**. Each rule has: - a **name**, such as "HTTP 5xx"; - a **filter**, written in exactly the same display-filter language as the filter bar; - a **foreground** (text) and **background** color. Because the filter is an ordinary display filter, everything that works in the filter bar works here: comparisons such as `http.response.code >= 500`, existence tests such as `tcp.analysis.retransmission`, sets, slices and searches. It is worth testing a rule's expression in the filter bar first, where a red bar shows a syntax error at once. ## The first match wins Rules are kept in an ordered list under **View > Coloring Rules...**. For each packet Wireshark tries them from the top and stops at the **first rule whose filter matches**; that rule's colors are used and the rules below it are never consulted for that packet. That is why order matters: 1. DNS is normally carried over UDP. 2. A rule with the filter `udp` matches every DNS-over-UDP packet. 3. If the `udp` rule sits above the `dns` rule, it matches first, and DNS packets get the UDP color. 4. Move the `dns` rule above the `udp` rule and DNS packets get their own color, while other UDP still gets the UDP color. The working rule: **specific rules above general ones**. ## Coloring versus filtering | | Display filter | Coloring rule | |---|---|---| | Effect on the packet list | hides packets that do not match | changes the colors of matching rows | | Context around a match | hidden | still visible | | Number active at once | one filter expression | many rules, first match wins | | Saved where | saved filters (`dfilters`) | the `colorfilters` file | On a capture of a failing web tier, coloring is the right tool when the neighbours of a failure matter: a rule on `http.response.code >= 500` paints the failing responses, and the requests, resets and retries around them stay on screen. A display filter is the right tool when you want the failures alone. ## Seeing which rule fired For a packet that a rule colored, Wireshark records that rule in the **Frame** section of Packet Details, as two fields: - `frame.coloring_rule.name`, the rule's name; - `frame.coloring_rule.string`, the rule's filter text. Both can be used in a display filter. `frame.coloring_rule.name == "HTTP 5xx"` lists every packet that rule colored, which is a quick way to check that a new rule catches what you expect and that a rule above it is not stealing its packets. ## Temporary and permanent rules - **Temporary rules** last until Wireshark quits. Create one by selecting a packet and pressing Ctrl with a number key, through the Color 1-10 entries of **View > Colorize Conversation** (Reset coloring clears them), or with **Colorize with Filter** on a field in Packet Details. The same submenu's New Coloring Rule... entry creates a permanent rule instead. - **Permanent rules** are made in the Coloring Rules dialog with the + button, edited by double-clicking the name or filter, and written to the personal `colorfilters` file when you press Save. Each configuration profile keeps its own `colorfilters`, so a profile built for web-tier work can carry its own rules. - **View > Colorize Packet List** switches colorization on and off without changing the rules; the user guide notes that colorization slows the display of new packets while capturing or loading files. ## Coloring on analysis flags Rules are a good home for the analyser's own flags, because a flag means most when you can see the packets around it. A rule on `tcp.analysis.retransmission` or `tcp.analysis.flags` placed near the top paints flagged packets while the conversation stays readable. The filter is only syntax here; what each flag says about the network, and whether it reflects the network or the capture, is Expert Info material. The default profile already ships rules of this kind, such as the one named Bad TCP. ## Practical guidance 1. Put narrow, high-signal rules (5xx responses, resets on your service port, retransmissions) at the top. 2. Keep broad protocol rules (`udp`, `tcp`, `arp`) near the bottom. 3. Give rules readable names, because the name is what `frame.coloring_rule.name` shows. 4. Share a profile rather than screenshots, so colleagues see the same colors for the same reasons.
- A new rule for `http.response.code >= 500` never colors anything, though the filter bar finds the packets. What do you check?Check the order first: a broader rule above it, such as one on `http` or `tcp`, matches those packets earlier and wins. Filter on `frame.coloring_rule.name` for a known failing packet to see which rule actually fired, then move the new rule above it. Also confirm that View > Colorize Packet List is switched on.
- Where are permanent coloring rules stored, and how do you give a team the same rules?Pressing Save in the Coloring Rules dialog writes them to the `colorfilters` file in the personal configuration folder, and each configuration profile keeps its own copy. Sharing a profile, or its `colorfilters` file, gives everyone the same ordered rules; temporary Color 1-10 rules from Colorize Conversation are not saved.
saying these in an interview costs you the question
- The most specific coloring rule wins wherever it sits in the list.
- Coloring rules use their own syntax, separate from display filters.
- A coloring rule hides the packets that do not match it.
- Colorize Conversation Color 1-10 rules survive a restart of Wireshark.
- Which rule colored a packet cannot be filtered on.