Wireshark’s default colorization rules are a surprisingly blunt instrument, often obscuring more than they reveal about network traffic.
Let’s see what a real-time capture looks like with a few custom rules applied. Imagine we’re troubleshooting a slow web application.
192.168.1.100.54321 > 192.168.1.1.80 TCP: Flags [S]
192.168.1.1.80 > 192.168.1.100.54321 TCP: Flags [S.]
192.168.1.100.54321 > 192.168.1.1.80 TCP: Flags [.]
192.168.1.100.54321 > 192.168.1.1.80 TCP: Flags [P.]
192.168.1.1.80 > 192.168.1.100.54321 TCP: Flags [.]
192.168.1.1.80 > 192.168.1.100.54321 TCP: Flags [P.]
192.168.1.100.54321 > 192.168.1.1.80 TCP: Flags [.]
192.168.1.100.54321 > 192.168.1.1.80 TCP: Flags [F.]
192.168.1.1.80 > 192.168.1.100.54321 TCP: Flags [.]
192.168.1.1.80 > 192.168.1.100.54321 TCP: Flags [F.]
This is just a basic TCP handshake and some data transfer. Without context, it’s hard to tell what’s important. But what if we want to highlight specific traffic?
Let’s say our web server is at 192.168.1.1 and our client is 192.168.1.100. We can create a rule to make all traffic between them stand out. Go to View > Coloring Rules... and click +. For "Coloring Rule":
- Match:
ip.addr == 192.168.1.100 && ip.addr == 192.168.1.1 - Color: Pick a bright yellow.
- Foreground: Black.
Now, all packets involving either 192.168.1.100 or 192.168.1.1 will be yellow. This immediately isolates our traffic of interest.
But we can go deeper. What about specific protocols or ports? Let’s make HTTP traffic (port 80) to our server a distinct color, say, blue.
- Match:
tcp.port == 80 && ip.dst == 192.168.1.1 - Color: Blue.
- Foreground: White.
And let’s highlight DNS traffic (port 53) in green, as it’s often a first step in name resolution.
- Match:
udp.port == 53 || tcp.port == 53 - Color: Green.
- Foreground: Black.
The power here is in layering these rules. Wireshark applies them in order, so a more specific rule will override a more general one if there’s a conflict. For instance, if we had a rule for all TCP traffic in red, the HTTP rule (blue) would take precedence for port 80 traffic to our server because it’s more specific.
Consider troubleshooting a slow connection. You might want to see retransmissions clearly.
- Match:
tcp.analysis.retransmission - Color: Red.
- Foreground: White.
Or perhaps identify packets with the PSH flag set, indicating data is ready to be sent immediately.
- Match:
tcp.flags.push == 1 - Color: Orange.
- Foreground: Black.
The Match field uses Wireshark’s display filter syntax. You can find many common filters by typing in the display filter bar at the top and seeing what the auto-completion suggests. For more complex logic, you can use && (AND), || (OR), and ! (NOT).
The real magic happens when you combine these. Imagine troubleshooting a VoIP call. You’d want to see RTP traffic (often UDP on ports like 16384-32767) in one color, SIP signaling (UDP/TCP port 5060) in another, and potentially DNS lookups for SIP servers in a third.
-
Match:
(udp.port >= 16384 && udp.port <= 32767) || (tcp.port >= 16384 && tcp.port <= 32767) -
Color: Purple.
-
Foreground: White.
-
Match:
(udp.port == 5060 || tcp.port == 5060) -
Color: Cyan.
-
Foreground: Black.
The system doesn’t just look at IP addresses and ports. You can colorize based on packet size, specific byte sequences within the payload, or even the presence or absence of certain TCP flags. For example, to highlight TCP packets with the FIN flag set (indicating the end of a connection):
- Match:
tcp.flags.fin == 1 - Color: Dark Gray.
- Foreground: White.
The key is that Wireshark evaluates these rules against every single packet in your capture. The order in the Coloring Rules dialog box matters. The first rule that matches a packet determines its color. This means you should put your most specific rules (e.g., a particular IP address and port combination) before more general rules (e.g., all traffic to an IP address).
Most people don’t realize that you can define rules based on the entire packet’s contents, not just simple header fields. For instance, if you’re hunting for a specific string within an HTTP POST request, you could create a rule like: http.request.method == "POST" && http contains "your_specific_string". This allows for incredibly granular analysis, turning a sea of packets into a visually navigable landscape.
Once you’ve defined your rules, remember to save them. Go to File > Export Settings... and choose "Coloring Rules" to save them to a .ini file. This allows you to easily load them onto another machine or restore them after a Wireshark update.
The next step is to understand how to write more complex display filters to isolate specific types of network conversations.