Packet analysis • PCAPs • TCP • DNS • Wireless labs

Advanced Wireshark is where packets become evidence.

Basic Wireshark teaches me how to capture packets and use simple filters. Advanced Wireshark is where I start asking better questions: what failed, who talked to who, which service responded, how long it took, and what the packet evidence actually proves.

This is the version I would use for deeper troubleshooting, CTF packet captures, honeynet review, server debugging, home lab analysis, and private wireless lab captures from a Raspberry Pi and Alfa adapter.

See the workflow Advanced filters
Important: packet captures can contain private data, device names, internal IPs, hostnames, cookies, tokens, and browsing metadata. I only capture traffic from my own devices, my own lab, CTF files, or environments where I have permission.
Capture or load PCAP Start with a focused file or controlled lab capture.
Summarize endpoints Find the hosts, ports, protocols, and conversations.
Filter and inspect Follow streams, check timing, and read protocol details.
Write the finding Turn packet evidence into a clear explanation.
Advanced Wireshark is less about clicking every packet and more about building a clean timeline from evidence.

Why go beyond basic captures?

A beginner capture answers “what packets do I see?” An advanced capture answers “what happened, why did it happen, and what evidence supports that conclusion?”

Troubleshooting

Find the failure point

I can separate DNS failure, TCP failure, TLS failure, HTTP failure, firewall behavior, retransmissions, resets, and application problems.

Forensics

Read PCAPs like evidence

In CTFs, honeynet logs, and security labs, a PCAP is a record of what happened. I can use Wireshark to build a timeline instead of guessing.

Wireless lab

Understand Wi-Fi behavior

With my own private lab and an Alfa adapter, I can study beacons, probes, channels, management frames, and encrypted traffic metadata safely.

My advanced Wireshark workflow

When a capture gets large, I do not start by clicking random packets. I start with structure: endpoints, conversations, protocols, timing, and then packet details.

01

Define the question

Am I investigating DNS, TCP, TLS, HTTP, DHCP, ARP, latency, failed login, or suspicious traffic?

02

Review statistics

I check endpoints, conversations, protocol hierarchy, and I/O graphs before drilling down.

03

Filter the capture

I use display filters to isolate one host, port, stream, protocol, or time window.

04

Write the answer

I document the packet numbers, timestamps, hosts, ports, and explanation.

My rule: if I cannot explain the capture in plain English, I do not understand it yet.

Start with Wireshark statistics

The statistics menus are underrated. They give me the map before I inspect individual packets.

Wireshark view What I use it for Why it matters
Protocol Hierarchy See which protocols appear in the capture. Quickly separates DNS, TCP, TLS, HTTP, DHCP, ARP, ICMP, and other traffic.
Endpoints List the IPs, MACs, and hosts involved. Helps identify the main devices before looking at packet details.
Conversations See which hosts talked to each other. Useful for finding the main client-server relationships.
I/O Graphs Visualize traffic over time. Helpful for bursts, scans, failures, retries, and timing patterns.
Resolved Addresses View resolved names from DNS and name resolution. Helps connect IPs to domains and hostnames.

Advanced display filters I actually use

Display filters are how I turn a huge capture into a focused investigation.

One host

Show traffic to or from one device.

ip.addr == 192.168.1.50

One conversation

Show traffic between two specific hosts.

ip.addr == 192.168.1.50 && ip.addr == 192.168.1.1

One TCP stream

After I right-click a packet and find the stream number, I can isolate it.

tcp.stream == 3

DNS errors

Useful when a site or service name does not resolve.

dns.flags.rcode != 0

TCP retransmissions

Useful for packet loss, congestion, or unreliable connections.

tcp.analysis.retransmission

TCP resets

Useful when connections are being forcefully closed.

tcp.flags.reset == 1

TLS handshakes

Useful for seeing encrypted connection setup.

tls.handshake

HTTP requests

Useful for plain HTTP labs and intentionally unencrypted test traffic.

http.request

Show SYN packets

Useful for watching connection attempts and scans in my lab.

tcp.flags.syn == 1 && tcp.flags.ack == 0

Find possible latency

Useful when Wireshark flags slow or duplicate acknowledgments.

tcp.analysis.ack_rtt
tcp.analysis.duplicate_ack

Follow streams instead of reading every packet

One of the most useful Wireshark features is “Follow TCP Stream.” It rebuilds a conversation so I can understand the exchange without reading every packet one at a time.

How I use it

Follow one conversation

  • Right-click a packet from the conversation.
  • Select Follow.
  • Choose TCP Stream, UDP Stream, or another stream type.
  • Read the reconstructed conversation.
  • Use the generated stream filter to isolate it.
Why it matters

It gives context

Individual packets are fragments. A stream shows the full exchange. This is useful for HTTP labs, CTFs, protocol debugging, and understanding client-server behavior.

Privacy note: following streams can reveal sensitive application data in unencrypted traffic. Do this only with your own traffic, lab traffic, or authorized PCAPs.

TCP troubleshooting checklist

TCP is where Wireshark becomes extremely useful. A connection problem usually leaves clues.

What I see Possible meaning Useful filter
SYN with no SYN-ACK The server may be down, filtered, blocked, or unreachable. tcp.flags.syn == 1
RST packet A host forcefully closed or refused the connection. tcp.flags.reset == 1
Retransmissions Packet loss, congestion, bad Wi-Fi, or path instability. tcp.analysis.retransmission
Duplicate ACKs The receiver may be missing data and asking for recovery. tcp.analysis.duplicate_ack
Long handshake time Latency, routing path, remote server delay, or network congestion. tcp.analysis.ack_rtt

DNS investigation workflow

DNS is one of the first things I check when a service “does not work.” Sometimes the network is fine, but name resolution is broken. 

# Generate a lookup
dig launchshell.org
dig example.com

# Wireshark filters
dns
dns.qry.name contains "launchshell"
dns.flags.rcode != 0
ip.addr == 1.1.1.1
ip.addr == 8.8.8.8

What name was requested?

I check the DNS query name and confirm the client asked for the name I expected.

Which DNS server answered?

I check whether the answer came from my router, Pi-hole, Cloudflare, Google, or another resolver.

Was there an error?

I look for NXDOMAIN, SERVFAIL, refused responses, or no response at all.

What IP came back?

I compare the returned address with what I expected.

TLS metadata: what I can still learn from encrypted traffic

HTTPS encrypts the content, but Wireshark can still show useful metadata. This is good for troubleshooting, but it is also a reminder that encrypted traffic still has visible patterns.

Visible metadata

What I can usually see

  • Client and server IP addresses
  • TCP ports
  • Connection timing
  • TLS handshake packets
  • Certificate details in some cases
  • Server Name Indication in some captures
Protected content

What should be encrypted

  • Page contents
  • Passwords
  • Session data
  • Form submissions
  • Most application payloads
# Useful TLS filters
tls
tls.handshake
tcp.port == 443
ip.addr == 192.168.1.50 && tcp.port == 443

Reading CTF and honeynet PCAPs

For CTFs and honeynet analysis, I usually start with the same questions every time.

01

Who are the hosts?

Use endpoints and conversations to identify clients, servers, and noisy systems.

02

What protocols appear?

Check protocol hierarchy before assuming the capture is about one service.

03

What stands out?

Look for errors, scans, unusual ports, repeated attempts, cleartext traffic, or bursts.

04

What is the timeline?

Use packet timestamps and streams to explain the order of events.

# Useful filters for PCAP review
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.flags.reset == 1
dns
http
ftp
smb || nbss
icmp
frame contains "password"
Careful: searching for strings like passwords should only be done in lab PCAPs, CTF files, honeynet data you collected, or captures you are authorized to review.

Wireless captures in my private lab

With a Raspberry Pi and Alfa Wi-Fi adapter, I can capture wireless frames in my own lab and analyze the PCAP files later in Wireshark. This is for learning and troubleshooting, not for spying on other people.

What I study

Safe wireless topics

  • Beacon frames from my own access point
  • SSID advertisements
  • Channel usage
  • Probe requests from my own test devices
  • Signal behavior and packet timing
  • Encrypted traffic metadata
Not covered

What this guide avoids

  • Cracking Wi-Fi passwords
  • Deauthentication attacks
  • Evil twin access points
  • Capturing traffic from networks I do not own
  • Collecting credentials or private data
Related project: build the Raspberry Pi + Alfa Wi-Fi Sniffer to capture private lab traffic and analyze the PCAP files in Wireshark.

Using tshark when Wireshark is too much

Wireshark is great visually, but tshark is better for quick summaries, scripts, servers, and repeatable analysis. 

# Basic pcap summary
tshark -r capture.pcap

# Show protocol hierarchy
tshark -r capture.pcap -q -z io,phs

# Show TCP conversations
tshark -r capture.pcap -q -z conv,tcp

# Show IP endpoints
tshark -r capture.pcap -q -z endpoints,ip

# Filter DNS packets
tshark -r capture.pcap -Y dns

# Filter one host
tshark -r capture.pcap -Y "ip.addr == 192.168.1.50"

My advanced Wireshark cheat sheet

This is the short version I would keep nearby when analyzing a real capture. 

# Core display filters
ip.addr == 192.168.1.50
ip.src == 192.168.1.50
ip.dst == 192.168.1.50
tcp.port == 22
tcp.port == 80
tcp.port == 443
udp.port == 53

# TCP analysis
tcp.stream == 3
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.flags.reset == 1
tcp.analysis.retransmission
tcp.analysis.duplicate_ack
tcp.analysis.ack_rtt

# DNS analysis
dns
dns.flags.rcode != 0
dns.qry.name contains "example"

# Web and TLS
http
http.request
http.response
tls
tls.handshake

# Local network protocols
arp
dhcp
icmp

# Command-line summaries
tshark -r capture.pcap -q -z io,phs
tshark -r capture.pcap -q -z conv,tcp
tshark -r capture.pcap -q -z endpoints,ip

Final idea

Advanced Wireshark is about evidence, not guessing. I use it to find the hosts, isolate the conversation, inspect the packets, explain the failure, and document what actually happened. It turns networking from something invisible into something I can prove with packet-level detail.