LFCE 97 🐧 Wireshark — GUI Analysis - KandZ

⏱️ Estimated read: 12 min | |

Wireshark is the graphical packet analyzer that turns a pcap file into an interactive investigation. The previous chapters covered tcpdump and tshark, which are the command-line tools for the capture and the extraction; this chapter covers the GUI that makes the protocol dissection visible, the conversations readable, and the anomalies color-coded. Wireshark is the tool that the administrator opens when the question is “what is actually happening on this connection” rather than “extract this field into a CSV.”

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The interface is built from three synchronized panes. The packet list pane shows the summary of every packet, the packet details pane shows the protocol tree of the selected packet, and the packet bytes pane shows the hex and ASCII of the same packet . The display filter toolbar sits above the list, and the coloring rules highlight the packets that match the specific conditions, such as the TCP errors and the HTTP failures . The statistics menu computes the protocol hierarchy, the conversations, and the endpoints, which are the summaries that answer “who talked to whom and how much” .

Key point: The display filter is the primary navigation tool. It uses the Wireshark field syntax, not the BPF syntax, and it is evaluated in the userspace against the decoded protocol fields. The “Follow TCP Stream” feature reassembles the individual packets into the complete conversation, which is the mechanism for reading the application-layer exchange as a single block of text . The coloring rules are processed top to bottom, and the first matching rule determines the packet’s color, which is why the custom rules must be placed above the default ones .

Why Wireshark requires the three-pane model

The packet-detail problem.

A packet is not a single field; it is a stack of protocol layers, each with its own headers and payload. The packet list shows only the summary, and the packet bytes show only the raw hex. The packet details pane is the middle ground: it shows the protocol tree with the dissected fields, and clicking a field highlights the corresponding bytes in the bytes pane . The three panes are synchronized, so the analyst can move from the summary to the field to the hex without losing the context.

The conversation problem.

A single packet is a fragment of a conversation. The “Follow TCP Stream” feature reconstructs the complete exchange from the individual packets, ordering them by the sequence number and displaying the client and server directions in the readable text . The stream view is the mechanism for the HTTP request and response, the SMTP session, and the other text-based protocols, where the individual packets are less meaningful than the complete dialogue.

The statistics problem.

The packet list shows the individual packets, but the summary questions—which protocol dominates, which host transferred the most data, which conversation lasted the longest—require the aggregation. The Statistics menu provides the protocol hierarchy, the conversations, and the endpoints, each of which is a different aggregation of the same capture . The right-click on a row applies the row’s condition as a display filter, which is the mechanism that pivots from the summary to the individual packets.

a. The display filter and the coloring rules

The display filter is the toolbar above the packet list. It accepts the Wireshark field syntax, and the packets that do not match are hidden from the list.

# The display filter examples
http
ip.addr == 192.168.1.50
tcp.flags.reset == 1
http.request.method in {"GET", "POST"}
tcp.port in {80, 443, 8080}

The http filter matches the packets that the dissector recognized as HTTP. The ip.addr filter matches the source or the destination address. The tcp.flags.reset == 1 matches the TCP resets. The in operator matches the membership in a set, and the tcp.port in {80, 443, 8080} is the compact form of the three or conditions . The display filter is evaluated against the decoded fields, which is why the http.request.method is available and the BPF filter cannot see it.

The coloring rules are the mechanism that highlights the packets without hiding them. The rules are processed top to bottom, and the first matching rule determines the color . The default rules include the “Bad TCP” for the retransmissions and the resets, the “HTTP” for the HTTP traffic, and the “Checksum Errors.” A custom rule can be created by right-clicking a field in the packet details and selecting “Colorize with Filter.”

# The custom coloring rule for the HTTP errors
http.response.code > 399

The rule matches the HTTP responses with the status code above 399, which covers the client errors (400–499) and the server errors (500–599) . The rule should be moved to the top of the list so that it takes precedence over the default HTTP rule.

b. The Follow TCP Stream

The “Follow TCP Stream” is the feature that reconstructs the complete conversation. It is available from the right-click menu on a TCP packet, or from the Analyze menu.

# The tshark equivalent of Follow TCP Stream
tshark -r capture.pcap -z follow,tcp,ascii,0 -q

The -z follow,tcp,ascii,0 option tells tshark to reconstruct the TCP stream with the index 0 and display the payload in the ASCII format . The -q option suppresses the packet output so that only the stream is printed. The output shows the client’s request and the server’s response in the order they occurred, with the different colors or the markers distinguishing the two directions.

The stream index is the tcp.stream field, which the dissector assigns to the packets that share the same connection endpoints. The tshark -T fields -e tcp.stream | sort -n | uniq command lists the stream indices in the capture . The GUI shows the same information in the “Follow TCP Stream” dialog, with the drop-down that selects the direction (client, server, or both) and the format (ASCII, EBCDIC, Hex Dump, or Raw).

c. The statistics and the expert information

The Statistics menu aggregates the capture into the summaries. The “Protocol Hierarchy” shows the tree of the protocols with the packet counts and the byte counts, which is the mechanism for the quick scope scan . The “Conversations” shows the talker and the listener pairs for the Ethernet, IPv4, IPv6, TCP, and UDP layers, with the byte counts and the durations. The “Endpoints” shows the unique participants per layer, which is the inventory of the assets involved .

The “Expert Information” shows the warnings and the errors that the dissector detected, such as the retransmissions, the duplicate ACKs, the malformed packets, and the application-layer errors. The expert information is the mechanism that surfaces the anomalies without the manual inspection of the individual packets.

The right-click on a row in the statistics applies the row’s condition as a display filter. The “Apply as Filter” on a protocol in the hierarchy, a conversation in the list, or an endpoint in the list pivots from the summary to the individual packets that match the selected condition . The pivot is the mechanism that connects the aggregate view to the packet-level detail.

Complete Example Session

# ============================================
# PART 1: OPEN THE CAPTURE
# ============================================
# File → Open → capture.pcap
# The packet list shows the summary

# ============================================
# PART 2: APPLY THE DISPLAY FILTER
# ============================================
# Type "http" in the filter toolbar and press Enter
# The list shows only the HTTP packets

# ============================================
# PART 3: INSPECT THE PACKET DETAILS
# ============================================
# Click an HTTP packet
# The details pane shows the Ethernet, IP, TCP, and HTTP layers
# Click the "Hypertext Transfer Protocol" field
# The bytes pane highlights the HTTP header

# ============================================
# PART 4: FOLLOW THE TCP STREAM
# ============================================
# Right-click the packet → Follow → TCP Stream
# The dialog shows the complete HTTP request and response

# ============================================
# PART 5: CREATE THE COLORING RULE
# ============================================
# Right-click the "Status Code" field → Colorize with Filter → New Coloring Rule
# Name: HTTP Errors, Filter: http.response.code > 399
# Move the rule to the top

# ============================================
# PART 6: PROTOCOL HIERARCHY
# ============================================
# Statistics → Protocol Hierarchy
# The tree shows the protocol breakdown

# ============================================
# PART 7: CONVERSATIONS
# ============================================
# Statistics → Conversations → TCP tab
# The list shows the connections and the byte counts

# ============================================
# PART 8: APPLY AS FILTER
# ============================================
# Right-click a conversation → Apply as Filter → Selected
# The packet list shows only that conversation

# ============================================
# PART 9: EXPERT INFORMATION
# ============================================
# Analyze → Expert Information
# The list shows the warnings and the errors

# ============================================
# PART 10: SAVE THE FILTERED CAPTURE
# ============================================
# File → Export Specified Packets → Displayed
# The filtered subset is saved to a new pcap

The ten parts demonstrate the Wireshark surface: the open, the display filter, the packet details, the follow stream, the coloring rule, the protocol hierarchy, the conversations, the apply-as-filter, the expert information, and the export. The critical navigation is Part 2 and Part 4: the display filter selects the traffic, and the follow stream reconstructs the conversation.

Quick Reference

The Three Panes

Pane	Content
Packet list	The summary of every packet
Packet details	The protocol tree of the selected packet
Packet bytes	The hex and ASCII of the selected packet

Display Filter Examples

Filter	Matches
`http`	HTTP packets
`ip.addr == 192.168.1.50`	Source or destination
`tcp.flags.reset == 1`	TCP resets
`http.request.method in {"GET", "POST"}`	GET or POST
`tcp.port in {80, 443, 8080}`	The three ports

Statistics Menu

Statistic	Purpose
Protocol Hierarchy	The protocol breakdown
Conversations	The talker-listener pairs
Endpoints	The unique participants
Expert Information	The warnings and errors

Follow TCP Stream

Step	Action
1	Right-click a TCP packet
2	Follow → TCP Stream
3	The dialog shows the conversation

Coloring Rules

Step	Action
1	Right-click a field
2	Colorize with Filter → New Coloring Rule
3	Enter the name and the filter
4	Move the rule to the top

Best Practices

✅ Do This:

# Use the display filter to narrow the view
http.request.method == "GET"                                   # ✅

# Use the Follow TCP Stream to read the conversation
Right-click → Follow → TCP Stream                              # ✅

# Create the custom coloring rule for the errors
http.response.code > 399                                       # ✅

# Use the Statistics menu for the summary
Statistics → Conversations → TCP                               # ✅

# Apply the summary row as a filter
Right-click → Apply as Filter → Selected                       # ✅

❌ Don’t Do This:

# Use the BPF syntax in the display filter
tcp port 80    # Use 'tcp.port == 80'                          # ❌

# Inspect the individual packets for the HTTP request
# Use the Follow TCP Stream instead                           # ❌

# Place the custom coloring rule at the bottom
# The default rule takes precedence                          # ❌

# Ignore the Expert Information
# The warnings and errors are the fastest path to the anomaly # ❌

# Apply the filter without checking the scope
# The filter hides the packets; verify the capture is complete # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
The filter syntax error	Used the BPF syntax	Use the Wireshark field syntax
The stream is unreadable	The payload is binary	Use the Hex Dump format
The custom color is not visible	The rule is below the default	Move it to the top
The statistics show the unwanted traffic	No display filter	Apply the filter before the statistics
The capture misses the packets	The promiscuous mode is off	Enable it in the capture options

Real-World Examples

1. Filter the HTTP traffic

http

2. Filter by the IP address

ip.addr == 192.168.1.50

3. Filter the TCP resets

tcp.flags.reset == 1

4. Follow the TCP stream

Right-click → Follow → TCP Stream

5. Create the HTTP error coloring rule

http.response.code > 399

6. Protocol hierarchy

Statistics → Protocol Hierarchy

7. Conversations

Statistics → Conversations → TCP

8. Apply as filter

Right-click → Apply as Filter → Selected

9. Expert information

Analyze → Expert Information

10. Export the filtered capture

File → Export Specified Packets → Displayed

Visual

The Three Panes

┌──────────────────────────────────────────────────────────────┐
│  THE THREE PANES ARE SYNCHRONIZED                            │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Packet list                                            │  │
│  │ No.  Time   Source      Destination   Protocol  Info   │  │
│  │ 1    0.000  192.168.1.5 10.0.0.1      TCP       ...    │  │
│  │ 2    0.001  10.0.0.1    192.168.1.5   HTTP      ...    │  │
│  └──────────────────────────┬─────────────────────────────┘  │
│                             │ click                          │
│                             ▼                                │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Packet details                                         │  │
│  │ ▸ Frame 2                                              │  │
│  │ ▾ Ethernet II                                          │  │
│  │ ▾ Internet Protocol                                    │  │
│  │ ▾ Transmission Control Protocol                        │  │
│  │ ▾ Hypertext Transfer Protocol                          │  │
│  └──────────────────────────┬─────────────────────────────┘  │
│                             │ click                          │
│                             ▼                                │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Packet bytes                                           │  │
│  │ 0000  47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

The Follow TCP Stream

┌──────────────────────────────────────────────────────────────┐
│  THE STREAM RECONSTRUCTS THE CONVERSATION                    │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ GET / HTTP/1.1                                         │  │
│  │ Host: example.com                                      │  │
│  │ User-Agent: curl/8.0                                   │  │
│  │                                                        │  │
│  │ HTTP/1.1 200 OK                                        │  │
│  │ Content-Type: text/html                                │  │
│  │ Content-Length: 1256                                   │  │
│  │                                                        │  │
│  │ <!DOCTYPE html>                                        │  │
│  │ <html>...                                              │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  The client request and the server response are shown in     │
│  the order the application experienced them.                 │
└──────────────────────────────────────────────────────────────┘

The Coloring Rules

┌──────────────────────────────────────────────────────────────┐
│  THE RULES ARE PROCESSED TOP TO BOTTOM                       │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ 1. HTTP Errors    http.response.code > 399   ← first   │  │
│  │ 2. Bad TCP        tcp.analysis.flags                   │  │
│  │ 3. HTTP           http                                 │  │
│  │ 4. TCP            tcp                                  │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  The HTTP error rule must be above the HTTP rule, or the     │
│  error response is colored as a normal HTTP packet.          │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Panes	Packet list, packet details, packet bytes
Display filter	The Wireshark field syntax
Follow TCP Stream	Reconstruct the complete conversation
Coloring rules	Top-to-bottom, first match wins
Protocol Hierarchy	The protocol breakdown
Conversations	The talker-listener pairs
Endpoints	The unique participants
Expert Information	The warnings and errors
Apply as Filter	Pivot from the summary to the packets

Key takeaways:

Wireshark is the graphical front-end of the same capture engine that tcpdump and tshark use. It adds the protocol dissection, the three synchronized panes, and the interactive filtering that make the investigation visual . The packet list shows the summary, the details show the protocol tree, and the bytes show the hex.
The display filter uses the Wireshark field syntax, not the BPF syntax. The http.request.method, the tcp.flags.reset, and the ip.addr are the decoded fields. The in operator matches the membership in a set, which is the compact form of the multiple or conditions .
The Follow TCP Stream reconstructs the conversation. It orders the packets by the sequence number and displays the client and server directions as a single block of text, which is the mechanism for the HTTP, the SMTP, and the other text-based protocols .
The coloring rules are processed top to bottom. The first matching rule determines the color, so the custom rules must be above the default ones. The right-click on a field creates the rule with the field’s condition, and the rule can be moved to the top .
The Statistics menu provides the aggregate view. The Protocol Hierarchy shows the protocol breakdown, the Conversations show the talker-listener pairs, and the Endpoints show the unique participants. The right-click applies the row as a display filter, which is the pivot from the summary to the packets .
The Expert Information surfaces the anomalies. The warnings and the errors that the dissector detected—the retransmissions, the resets, the malformed packets—are listed in the Expert Information, which is the fastest path to the problem without the manual inspection.

Remember: Wireshark is the GUI that makes the packet capture readable. The three panes are synchronized, the display filter selects the traffic, and the Follow TCP Stream reconstructs the conversation. The coloring rules highlight the anomalies, and the Statistics menu aggregates the capture. The Expert Information surfaces the warnings, and the Apply as Filter pivots from the summary to the packets. The result is a tool that turns the raw pcap into an investigation, where the question “what happened on this connection” is answered by the protocol tree, the stream, and the statistics.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!