Wireshark is a network protocol analyzer that captures network traffic and decodes packets so engineers can inspect communications at the protocol and field level.
It can show:
Ethernet
↓
ARP
↓
IPv4 / IPv6
↓
TCP / UDP / ICMP
↓
DNS / HTTP / TLS / DHCP
↓
Application-level protocol fields
Unlike a simple network monitor that might report:
CPU = 45%
Bandwidth = 600 Mbps
Wireshark can help answer much more precise questions:
Which host sent the packet?
Which destination was contacted?
Did the TCP three-way handshake complete?
Was DNS successful?
Did the client retransmit packets?
Which TCP flags were set?
Which TLS messages were exchanged?
Did the server respond with an RST?
Wireshark’s official documentation describes three primary packet-analysis views: a summary packet list, detailed protocol/field information, and a hexadecimal representation of the packet. It also supports reconstructing protocol conversations such as TCP streams. (Wireshark User’s Guide; Wireshark manual)
This makes Wireshark one of the most useful tools for network engineers, system administrators, DevOps engineers, security analysts and developers.
For the broader networking foundation, see Computer Networking Explained and TCP/IP Explained.
Wireshark consists conceptually of several stages:
Network Interface
|
v
Packet Capture
|
v
libpcap / Npcap
|
v
Wireshark
|
v
Protocol Dissection
|
v
Filters / Statistics / Analysis
|
v
Human Interpretation
On systems that support live capture, Wireshark uses packet-capture facilities such as libpcap; on Windows, current Wireshark packages include Npcap for live packet capture. (Wireshark Download)
The important distinction is:
Wireshark does not create network traffic.
It observes captured traffic.
These are two different activities.
Capture traffic from an interface:
Network
↓
NIC
↓
Capture subsystem
↓
PCAP/PCAPNG
Take that capture and ask:
What happened?
Why did it happen?
Where did it happen?
Which protocol is involved?
Which host is responsible?
This separation is important because a poor capture can limit what can be concluded later.
A technically perfect filter cannot recover packets that were never captured.
When you start Wireshark, one of the first tasks is selecting the correct interface.
Typical interfaces include:
Ethernet
Wi-Fi
Loopback
VPN
Virtual Ethernet
Docker bridge
Hypervisor adapter
You may see names such as:
eth0
ens33
enp0s3
wlan0
Wi-Fi
Ethernet
The correct interface depends on where the traffic exists.
Suppose your application communicates through:
Wi-Fi
but you capture:
Ethernet
You may see little or no relevant traffic.
Similarly, if a container communicates internally through a virtual bridge, capturing only a physical interface may not expose everything you expected.
The first question should therefore always be:
Where does the packet physically or virtually enter and leave this system?
Wireshark can request promiscuous mode during capture.
In simplified terms, promiscuous mode allows an interface to receive frames beyond those normally addressed specifically to that interface, subject to the capabilities and topology of the environment.
However, promiscuous mode does not mean:
“I can see all traffic on the network.”
A switched Ethernet network normally forwards unicast traffic only toward the appropriate switch port.
Therefore a workstation attached to a normal switch will not automatically see every packet generated by every other workstation.
Wireshark’s FAQ explicitly notes that promiscuous mode does not guarantee visibility of non-broadcast traffic belonging to other hosts. (Wireshark FAQ)
To capture traffic not destined for your own machine, organizations may use:
SPAN / Port Mirroring
Network TAP
Virtual switch mirroring
Cloud traffic-mirroring mechanisms
Conceptually:
Switch
/ | \
/ | \
Host A Host B Host C
|
Mirror Source
|
v
Wireshark Sensor
This is a fundamentally different observation point from capturing traffic directly on an endpoint.
Wireshark’s main analysis window provides three important areas.
Shows a summary:
No.
Time
Source
Destination
Protocol
Length
Info
Example:
1
0.000000
192.168.1.10
1.1.1.1
DNS
76
Standard query
Expands protocol layers:
Frame
Ethernet II
Internet Protocol Version 4
User Datagram Protocol
Domain Name System
Displays the actual bytes.
This creates a powerful relationship:
Summary
↓
Protocol Structure
↓
Raw Bytes
The official Wireshark manual documents all three views and explains how to navigate individual protocol fields. (Wireshark manual)
A useful analysis habit is to move from the lower layers upward.
Example:
Frame
↓
Ethernet II
↓
IPv4
↓
TCP
↓
TLS
↓
Application
Ask questions at every layer:
Ethernet:
Which MAC addresses?
IP:
Which endpoints?
TCP:
Which ports and flags?
TLS:
Did encryption negotiation succeed?
Application:
What protocol behavior occurred?
This layered approach connects naturally with TCP/IP Explained.
This is one of the most important Wireshark concepts.
Wireshark uses two different filtering languages:
Capture Filters
Display Filters
They are not interchangeable.
The official Wireshark documentation explicitly states that capture filters and display filters use different syntax. (Wireshark User’s Guide; Capture Filters)
Capture filters are applied before or during packet capture to limit what gets captured.
Example:
tcp port 443
This can reduce the volume of traffic written into the capture.
Capture-filter syntax is based on the packet-filter syntax used by libpcap/tcpdump. (Wireshark CaptureFilters)
Typical examples:
host 192.168.1.10
port 53
tcp port 443
icmp
net 192.168.1.0/24
Display filters operate on packets that have already been captured.
Example:
tcp.port == 443
You can change display filters repeatedly without starting the capture again.
Official Wireshark documentation describes display filters as a powerful way to restrict the packets shown based on protocols, fields and field values. (Wireshark User’s Guide; wireshark-filter)
| Objective | Capture Filter | Display Filter |
|---|---|---|
| Applied | During capture | After capture |
| Main purpose | Reduce captured traffic | Analyze captured traffic |
| Syntax | libpcap-style | Wireshark display-filter language |
| Example | tcp port 443 | tcp.port == 443 |
| Can change after capture? | No | Yes |
The most common beginner mistake is using:
tcp.port == 443
as a capture filter.
That is a display-filter expression.
Conversely:
tcp port 443
is a capture-filter expression.
Wireshark documents this distinction explicitly. (Wireshark CaptureFilters)
Here are some of the most useful display filters.
tcp
udp
dns
icmp
ipv6
tcp.port == 443
ip.addr == 192.168.1.10
ip.src == 192.168.1.10
ip.dst == 192.168.1.10
These are examples of Wireshark’s display-filter language. The official display-filter reference is maintained by the Wireshark project. (Display Filter Reference)
Filters can be combined using logical operators.
Example:
ip.addr == 192.168.1.10 && tcp.port == 443
This means:
IP address = 192.168.1.10
AND
TCP port = 443
Another example:
dns || icmp
This displays DNS or ICMP traffic.
The official wireshark-filter documentation describes combining expressions using logical operators and other filtering constructs. (wireshark-filter)
TCP flags provide a powerful way to locate important events.
For example:
tcp.flags.syn == 1
SYN packets.
tcp.flags.ack == 1
ACK packets.
tcp.flags.reset == 1
RST packets.
tcp.flags.fin == 1
FIN packets.
You can combine:
tcp.flags.syn == 1 && tcp.flags.ack == 0
to focus on initial SYN requests.
One of the most useful Wireshark analysis features is identifying TCP retransmissions.
A display filter such as:
tcp.analysis.retransmission
can reveal packets Wireshark has classified as retransmissions.
Other TCP analysis fields include:
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.zero_window
The exact protocol fields available can be explored through Wireshark’s Display Filter Reference. (Display Filter Reference)
A retransmission is not automatically proof of:
“The network is broken.”
Possible explanations include:
Packet loss
Congestion
Wireless interference
Delayed ACK
Network reordering
Receiver behavior
Capture-point limitations
The important question is:
Why was the segment retransmitted?
This requires examining the surrounding packets.
TCP is one of Wireshark’s most valuable protocol dissectors.
A normal TCP connection begins with:
Client → SYN
Server → SYN, ACK
Client → ACK
This is the three-way handshake.
Graphically:
Client Server
| -------- SYN ------------> |
| <------ SYN + ACK -------- |
| -------- ACK ------------> |
After that:
Application Data
can flow over the established TCP session.
Filter:
tcp.flags.syn == 1
Then inspect the packet details.
Important fields include:
Source Port
Destination Port
Sequence Number
Acknowledgment Number
Window Size
TCP Options
MSS
Window Scale
SACK
Timestamps
TCP options can provide important clues about the negotiated transport behavior.
Suppose you see:
Client → SYN
Client → SYN
Client → SYN
but no:
Server → SYN/ACK
This strongly suggests that the TCP handshake is not completing.
Possible causes include:
Firewall
ACL
Routing problem
Server unavailable
Wrong destination IP
Packet filtering
Network failure
The capture proves what the client sent and what it did or did not receive.
That is much stronger evidence than simply saying:
“The connection timed out.”
Filter:
tcp.flags.reset == 1
An RST can indicate that a connection was actively reset.
Possible causes include:
Application refusing a connection
Closed port
Firewall behavior
Protocol violation
Application shutdown
Middlebox behavior
The surrounding packets determine the actual meaning.
A graceful TCP close generally uses FIN.
An abrupt reset uses RST.
Conceptually:
FIN
↓
Graceful close
RST
↓
Abort / reset
Therefore a cluster of unexpected RST packets can be a useful clue during troubleshooting.
A TCP receiver advertises a receive window.
If the receiver cannot accept more data temporarily, it can advertise a small or zero receive window.
Wireshark can help identify:
tcp.analysis.zero_window
This may indicate receiver-side pressure.
Potential causes include:
Application not reading data
CPU saturation
Memory pressure
Slow processing
Receive-buffer limitations
Again, the capture identifies the transport symptom; additional evidence is required to identify the exact root cause.
A common pattern:
Server → Data
Client → ACK
Client → Window = 0
The sender may then have to pause.
This can produce poor application performance even when:
Packet loss = 0%
That is why:
Bandwidth ≠ performance
A TCP flow can be slow because the receiver is not consuming data fast enough.
Wireshark timestamps every captured packet.
This allows analysis of:
Handshake delay
Server response delay
Retransmission interval
ACK timing
Application latency
Connection teardown
Use:
View → Time Display Format
and packet timestamps to analyze the timing relationship.
For serious analysis, always distinguish:
Network delay
Server processing delay
Client processing delay
rather than treating total application response time as pure network latency.
One of Wireshark’s useful capabilities is reconstructing packets belonging to a TCP conversation.
Select a TCP packet and use:
Right Click
→ Follow
→ TCP Stream
This groups packets belonging to a conversation and presents the reconstructed stream.
Wireshark’s documentation specifically identifies TCP stream reconstruction as one of its protocol-analysis capabilities. (Wireshark manual)
This can be useful for:
HTTP
Text protocols
Application debugging
Legacy unencrypted protocols
For encrypted HTTPS traffic, the application payload remains protected unless appropriate decryption material is available and legally authorized.
Wireshark can also summarize conversations.
Conceptually:
Client A ↔ Server A
Client B ↔ Server A
Client C ↔ Server B
This can help identify:
Top talkers
High-volume conversations
Unexpected endpoints
Long-lived flows
Conversation analysis is especially useful in large packet captures where manually examining every packet would be inefficient.
DNS is another area where Wireshark becomes extremely useful.
Filter:
dns
You can inspect:
Queries
Responses
Transaction IDs
Query types
Response codes
Answers
Authorities
Additional records
This connects directly with DNS Explained.
Suppose a client requests:
api.example.com
You may see:
Client → DNS Server
Standard Query: A api.example.com
Then:
DNS Server → Client
Standard Query Response
Expand:
Domain Name System
and inspect:
Queries
Answers
TTL
Addresses
Response Code
Important DNS response states include:
NOERROR
NXDOMAIN
SERVFAIL
REFUSED
The DNS transaction completed without a DNS error at the protocol level.
The queried domain name does not exist according to the responding DNS server.
The server could not successfully complete the query.
The server refused to perform the query.
Wireshark helps you see which response was actually transmitted rather than relying solely on application error messages.
DNS is frequently blamed when websites are slow.
Wireshark allows you to measure:
Query timestamp
Response timestamp
Then compare:
DNS response time
TCP connection time
TLS handshake time
Application response time
This can reveal whether DNS is actually the bottleneck.
Look for:
Repeated queries
Same transaction behavior
Delayed response
Multiple resolvers
Potential causes include:
Packet loss
Slow DNS server
Unavailable resolver
Network filtering
Application retry behavior
Wireshark provides packet-level evidence.
For unencrypted HTTP traffic, Wireshark can decode:
GET
POST
HEAD
PUT
DELETE
HTTP response
Headers
Status codes
Filter:
http
Then inspect:
http.request
http.response
depending on the capture and protocol dissection.
For application troubleshooting, this can reveal the actual client/server exchange.
Common examples:
200 OK
301 Moved Permanently
302 Found
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
Seeing the response in the capture can distinguish:
Network connection successful
but application returned an error
from:
Connection never reached the application
Modern web traffic is usually protected with TLS.
You will typically see:
TCP
↓
TLS
↓
Encrypted Application Data
Wireshark can decode TLS protocol metadata even when the application payload remains encrypted.
Depending on the capture and TLS version, you may inspect information such as:
Client Hello
Server Hello
Extensions
Cipher negotiation
Certificate messages
Alerts
Application Data
Filter:
tls.handshake.type == 1
This identifies TLS Client Hello messages in captures where Wireshark dissects the traffic accordingly.
The Client Hello can contain information such as:
Supported versions
Cipher suites
Extensions
Server Name Indication
Application-Layer Protocol Negotiation
This is useful when troubleshooting TLS negotiation.
A client may provide a server name through the TLS handshake.
This can help determine which hostname the client intended to reach, subject to protocol version and encryption behavior.
A filter can be built around the relevant TLS fields using Wireshark’s display-filter reference.
The current Wireshark filter reference contains a very large and continuously maintained collection of protocol fields. (Wireshark Display Filter Reference)
TLS problems can occur after TCP has succeeded.
Example:
TCP SYN
TCP SYN/ACK
TCP ACK
TLS Client Hello
TLS Server response
TLS Alert
This sequence tells you something important:
Network path works
TCP works
TLS negotiation fails
That dramatically narrows the troubleshooting scope.
ICMP is important for network troubleshooting.
Filter:
icmp
For IPv6:
icmpv6
You can investigate:
Echo Request
Echo Reply
Destination Unreachable
Time Exceeded
Packet Too Big
This complements the ping and traceroute techniques discussed in the CorgiNetwork networking and Linux administration content.
A ping generates:
Echo Request
and normally expects:
Echo Reply
Wireshark allows you to inspect:
Identifier
Sequence
Payload
Timestamp
Source
Destination
If you see the request but not the reply, the next question becomes:
Where did the reply disappear?
A useful ICMP response may explain why a packet cannot reach its destination.
Depending on the type and code, it may point toward:
No route
Port unreachable
Administratively prohibited
Packet too big
The exact interpretation depends on the ICMP message.
This is particularly useful when troubleshooting firewalls and routing.
For IPv4 local networks, ARP resolves an IPv4 address to a Layer-2 hardware address.
Typical exchange:
Who has 192.168.1.1?
192.168.1.1 is at aa:bb:cc:dd:ee:ff
Filter:
arp
This is useful for investigating:
Duplicate addresses
Neighbor discovery problems
Unexpected MAC mappings
Local connectivity failures
ARP storms
For broader networking fundamentals, see Routers, Switches and Network Devices.
Suppose:
ip route
looks correct.
But:
ping gateway
fails.
Capture:
arp
If you see repeated:
Who has gateway-IP?
with no reply, investigate:
VLAN
Switch port
ARP filtering
Layer-2 connectivity
Host firewall
Duplicate IP
Wireshark can therefore expose a problem below the IP layer.
IPv6 does not use ARP.
Instead, IPv6 uses Neighbor Discovery Protocol (NDP) through ICMPv6.
Capture:
icmpv6
and inspect neighbor-related messages.
This is important when troubleshooting dual-stack environments because an IPv4-only diagnostic approach can miss IPv6 problems.
Wireshark can also help analyze DHCP traffic.
For IPv4:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Conceptually:
Client DHCP Server
| ---- Discover ----> |
| <----- Offer ------ |
| ----- Request ----> |
| <------ ACK ------- |
A filter such as:
dhcp
may be appropriate depending on the protocol dissection and capture.
DHCP analysis can reveal:
No offer
Wrong DHCP server
Incorrect address
Unexpected options
Lease problems
The broader protocol concepts are covered in DHCP Explained.
Wireshark can dissect VLAN-tagged Ethernet frames.
Look for:
802.1Q
and fields such as:
VLAN ID
Priority
A VLAN issue may manifest as:
Correct IP configuration
Correct route
But no local communication
Packet capture can reveal whether the expected VLAN tag exists.
A professional troubleshooting method starts with a question.
Bad approach:
Open Wireshark
Look at random packets
Better approach:
Define symptom
↓
Define expected behavior
↓
Capture at correct observation point
↓
Filter relevant traffic
↓
Follow packet sequence
↓
Identify divergence
↓
Form hypothesis
↓
Validate hypothesis
This is the central skill.
Suppose:
Browser:
Connection timed out
Do not immediately blame DNS.
Capture traffic while reproducing the problem.
Then examine:
DNS
↓
TCP
↓
TLS
↓
HTTP
Possible result:
DNS query
DNS response
TCP SYN
TCP SYN
TCP SYN
No SYN/ACK.
That suggests the problem is occurring before TLS and HTTP.
The likely investigation area becomes:
Routing
Firewall
ACL
Server reachability
Packet filtering
Capture:
dns
and then:
tcp.port == 443
You may discover:
DNS response successful
TCP handshake successful
TLS Client Hello
TLS Alert
Now:
DNS = working
TCP = working
TLS = failing
That is a much narrower problem.
Filter:
tcp.analysis.retransmission
If many retransmissions appear, inspect:
Sequence numbers
ACKs
Timing
Window size
Direction
Also look at:
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
This can help distinguish:
Packet loss
Reordering
Receiver problems
Congestion
from purely application-level delays.
Look for:
tcp.flags.reset == 1
Suppose:
Client → SYN
Server → RST, ACK
This can indicate that the destination host or a network device actively rejected the connection.
Next investigate:
Listening service
Firewall
Application state
Load balancer
On Linux, ss can help determine whether the expected service is actually listening:
ss -lntup
This creates a powerful combination:
Wireshark
+
ss
Suppose the capture shows:
TCP handshake
TLS handshake
HTTP request
HTTP/1.1 503 Service Unavailable
The important conclusion is:
Network connectivity worked.
The problem is now above basic connectivity.
Potential investigation areas include:
Reverse proxy
Upstream application
Load balancer
Application pool
Backend health
Wireshark helps establish where the failure occurred.
Wireshark can save captured traffic to files for later analysis.
Common formats include:
PCAP
PCAPNG
Modern Wireshark uses PCAPNG as its native capture format, while also reading other supported capture formats. TShark documentation also identifies pcapng as the native capture file format shared with Wireshark. (TShark manual)
A basic workflow is:
Capture
↓
Save
↓
capture.pcapng
↓
Analyze later
A capture can become evidence.
For example:
Incident at 14:32
↓
Capture saved
↓
Engineer investigates
↓
Security team reviews
↓
Root cause documented
For complicated incidents, preserving the original capture can be extremely valuable.
For security investigations, it is useful to preserve:
Original file
Timestamp
Capture location
Capture interface
Capture tool/version
Analyst notes
For more formal investigations, consider cryptographic hashing:
sha256sum incident.pcapng
This provides a reproducible fingerprint for the file.
From Wireshark’s GUI:
File
→ Open
→ capture.pcapng
From the command line:
wireshark capture.pcapng
Or analyze without GUI using TShark:
tshark -r capture.pcapng
TShark supports reading saved captures and decoding packets from the command line. (TShark manual)
TShark is the command-line protocol analyzer distributed with Wireshark.
It can:
Capture traffic
Read capture files
Apply display filters
Decode protocols
Export data
Automate analysis
The official manual describes TShark as a network protocol analyzer that can capture live traffic or read previously saved captures. (TShark manual)
List interfaces:
tshark -D
Capture on an interface:
tshark -i 1
Apply a capture filter:
tshark -i 1 -f "tcp port 443"
Read a saved capture:
tshark -r capture.pcapng
Read a capture and show only TCP:
tshark -r capture.pcapng -Y "tcp"
Only DNS:
tshark -r capture.pcapng -Y "dns"
Only HTTP:
tshark -r capture.pcapng -Y "http"
Only retransmissions:
tshark -r capture.pcapng -Y "tcp.analysis.retransmission"
The -Y option uses Wireshark’s display-filter syntax. (TShark manual; wireshark-filter)
Both are valuable, but they have different strengths.
| Capability | tcpdump | TShark |
|---|---|---|
| Lightweight capture | Excellent | Excellent |
| Capture filters | Yes | Yes |
| Display filters | Limited compared with Wireshark | Wireshark display-filter engine |
| Protocol dissection | Good | Extensive |
| Automation | Excellent | Excellent |
| GUI | No | No |
| Deep Wireshark analysis | No | Yes |
A common workflow is:
tcpdump / TShark
↓
PCAPNG
↓
Wireshark
↓
Deep analysis
Wireshark can be extremely useful for authorized defensive analysis.
Possible activities include:
Unexpected outbound connections
Suspicious DNS traffic
Port scanning analysis
Protocol anomalies
Malware traffic investigation
C2 traffic investigation
Credential exposure in plaintext protocols
Network-policy verification
However:
A packet capture is evidence, not automatically a diagnosis.
A suspicious-looking packet must be interpreted within context.
A useful starting filter is:
dns
Then investigate:
Query frequency
Destination DNS servers
Unusual domains
Repeated NXDOMAIN
Long labels
Unexpected TXT queries
The presence of one unusual DNS request does not establish malicious activity.
Context matters.
Use:
tcp
then analyze:
ip.dst
tcp.dstport
Look for unexpected patterns:
Unknown destination
Unusual port
Repeated failed connections
Periodic connections
Multiple destinations
Then correlate with the host process information.
On Linux:
ss -tp
can help connect network sockets to processes.
This creates a useful workflow:
Wireshark
↓
Remote endpoint identified
↓
ss
↓
Local process identified
A packet capture may show one source contacting many destination ports or many hosts.
Conceptually:
Host A
|
+--> Host B:22
+--> Host B:23
+--> Host B:25
+--> Host B:80
+--> Host B:443
+--> Host B:445
Possible indicators include:
Many SYN packets
Many destinations
Many destination ports
High number of failed connections
But legitimate vulnerability scanners and administrative tools can produce similar traffic.
Therefore packet behavior must be correlated with known activity.
A simplified pattern:
SYN
SYN
SYN
SYN
SYN
toward many ports may indicate a scan.
Filter:
tcp.flags.syn == 1 && tcp.flags.ack == 0
Then examine:
ip.src
ip.dst
tcp.dstport
This creates a useful first-pass view of SYN-based connection attempts.
Some protocols may expose credentials without encryption.
Historically common examples include:
HTTP
FTP
Telnet
A capture of such traffic can potentially expose credentials or other sensitive application data.
This is one reason encrypted protocols such as HTTPS and SSH are essential.
Do not capture, inspect or retain sensitive user traffic unless you are authorized to do so.
Suppose a firewall rule is intended to block:
TCP/23
You can validate the result from the correct capture point.
For example:
Client
|
| TCP/23
v
Firewall
X
Server
Wireshark can help determine whether:
Packet leaves client
Packet reaches firewall
Packet passes firewall
Packet reaches server
Server responds
This is much more precise than simply saying:
“The firewall should block it.”
See Firewalls Explained for the broader security architecture.
VPN traffic can be difficult to diagnose because payloads may be encrypted.
Still, captures can reveal:
Tunnel establishment
IPsec packets
TLS/DTLS
Keepalives
Retransmissions
Packet size
Fragmentation
Connection resets
This helps determine whether the VPN issue occurs at:
Control plane
Transport
Tunnel
Routing
Application
For foundational VPN architecture, see VPNs Explained.
Virtual environments may involve:
Guest
↓
Virtual NIC
↓
Virtual switch
↓
Hypervisor
↓
Physical NIC
↓
Network
Capturing at different layers can reveal different views.
A packet visible inside the guest may not necessarily be visible in the exact same way at the physical NIC.
This is why capture location matters.
The underlying architecture is covered in Virtualization Explained.
On Linux, a strong troubleshooting stack is:
ip
ss
dig
curl
tcpdump
Wireshark
Each answers a different question.
ip
→ Host network state
ss
→ Sockets and processes
dig
→ DNS
curl
→ Application behavior
tcpdump
→ Packet capture
Wireshark
→ Deep packet analysis
For Linux administration fundamentals, see Linux Server Administration.
SNMP monitoring might report:
Interface errors increasing
Wireshark can then help investigate the actual packet behavior.
For example:
SNMP monitoring
↓
Interface anomaly
↓
Wireshark capture
↓
TCP retransmissions
↓
Packet-level investigation
This illustrates an important operational model:
Monitoring identifies the symptom.
Packet analysis helps investigate the mechanism.
A SIEM may report:
Suspicious connection
Wireshark can potentially provide packet-level context.
A SOC workflow may look like:
SIEM Alert
↓
Identify host
↓
Identify timestamp
↓
Retrieve PCAP
↓
Filter traffic
↓
Analyze protocol
↓
Correlate with logs
↓
Incident assessment
See SIEM Explained for the broader event-correlation architecture.
Now move from theory to practice.
The goal is to capture and analyze:
DNS
TCP
HTTPS
from one Linux or Windows workstation.
Internet
|
v
DNS / HTTPS Server
|
Network
|
v
Test Workstation
|
Wireshark
You should perform this only on systems and networks you are authorized to monitor.
Open Wireshark and select the interface that carries your internet traffic.
For a normal desktop this might be:
Wi-Fi
or:
Ethernet
Start the capture.
Open a terminal:
nslookup example.com
or:
dig example.com
On Windows:
nslookup example.com
Now return to Wireshark and use:
dns
as the display filter.
Select a DNS packet.
Expand:
Domain Name System
Look for:
Queries
Name
Type
Class
Then find the matching response.
You should be able to identify:
Client IP
DNS Server IP
Requested hostname
Record type
Response
Open:
https://example.com
Now filter:
tcp.port == 443
You should see TCP and TLS traffic.
Look for:
SYN
SYN/ACK
ACK
This demonstrates that the TCP connection was established before TLS application data was exchanged.
A useful filter is:
tcp.flags.syn == 1
Then inspect the sequence of packets.
Use:
tls
Then look for:
Client Hello
Server Hello
Certificate-related messages
Encrypted Application Data
The exact handshake visibility depends on the TLS version and capture.
Try:
tcp.analysis.retransmission
If no packets appear, that is not proof that the path is perfect; it only means Wireshark did not classify packets in the capture as retransmissions under that filter.
This is an important analytical principle:
Absence of an observation is not always proof of absence of the underlying condition.
Right-click a relevant TCP packet:
Follow
→ TCP Stream
For encrypted HTTPS, the stream will not expose plaintext application content simply because it is viewed as a stream.
The capture still provides transport and TLS metadata.
Wireshark provides statistics and analysis features for:
Conversations
Endpoints
Protocol hierarchy
I/O graphs
Flow graphs
These features can help move from:
Individual packet
to:
Traffic pattern
An I/O graph can help visualize traffic over time.
For example:
Packets/sec
Bytes/sec
Traffic by filter
This can reveal:
Burst
Idle period
Retransmission event
Traffic spike
Throughput change
Graphing becomes especially useful when a packet capture contains millions of packets.
The protocol hierarchy provides a high-level overview.
For example:
Ethernet
|
+-- IPv4
|
+-- TCP
|
+-- TLS
This helps answer:
What kind of traffic is actually in this capture?
An experienced analyst generally moves through stages:
1. Capture point
↓
2. Scope
↓
3. Protocol hierarchy
↓
4. Conversations
↓
5. Relevant endpoints
↓
6. Display filter
↓
7. Packet sequence
↓
8. Timing
↓
9. Protocol fields
↓
10. Hypothesis
↓
11. Validation
This avoids drowning in packets.
Wireshark’s display-filter language can inspect:
Protocol
Field existence
Exact values
Ranges
Comparisons
Nested fields
Logical expressions
Regular expressions
The official filter manual documents comparisons, logical operators, field references, functions and more. (wireshark-filter)
Examples:
tcp.port == 443
ip.src == 192.168.1.10
dns.qry.name == "example.com"
tcp.analysis.retransmission
A powerful filter can be:
dns.qry.name == "example.com"
This lets you focus on queries for one hostname rather than every DNS packet.
Another useful pattern:
dns.qry.name contains "example"
The precise field and operator behavior should always be checked against the installed Wireshark version and its current filter reference. (wireshark-filter)
For decoded HTTP traffic, a filter may be based on:
http.request.method == "GET"
or:
http.request.method == "POST"
This allows analysts to focus on specific application operations.
For decoded HTTP response traffic:
http.response.code == 500
can isolate server errors.
Likewise:
http.response.code == 404
can isolate not-found responses.
This becomes useful during application troubleshooting.
TCP uses sequence and acknowledgment numbers to track reliable delivery.
In Wireshark you can inspect:
Sequence Number
Acknowledgment Number
Next Sequence Number
Relative Sequence Number
Relative sequence numbering makes captures easier to read.
The key relationship is:
Sender:
Sequence N
Receiver:
ACK N + payload length
This allows you to reason about:
Data received
Missing segments
Retransmission
Ordering
Wireshark can flag:
tcp.analysis.out_of_order
Out-of-order delivery is not automatically a failure.
Packets can legitimately arrive in a different order from transmission due to network behavior.
The important questions are:
Are packets later reordered successfully?
Are retransmissions occurring?
Is application performance affected?
Filter:
tcp.analysis.duplicate_ack
Duplicate ACK patterns can be associated with missing segments and fast retransmission behavior.
Again, they are clues rather than final diagnoses.
Wireshark may identify:
tcp.analysis.fast_retransmission
This is useful when diagnosing packet loss and TCP recovery behavior.
A meaningful analysis should correlate:
Duplicate ACK
Missing sequence range
Retransmitted packet
Timing
rather than looking at one flag in isolation.
A flow can have:
High link capacity
but:
Low application throughput
Wireshark can help investigate:
Retransmissions
Window limitations
RTT
ACK behavior
Packet size
Application request pattern
This is a powerful reminder:
The physical link speed is not equal to the application’s usable throughput.
For HTTPS problems:
1. DNS
↓
2. TCP handshake
↓
3. TLS Client Hello
↓
4. TLS Server response
↓
5. Certificate / negotiation
↓
6. Encrypted application traffic
If the capture stops at:
TCP handshake
investigate networking.
If it reaches:
TLS
but fails there, investigate:
Certificates
TLS versions
Cipher compatibility
SNI
ALPN
Middleboxes
Policy
Modern web traffic may not use classic HTTP/1.1.
You may encounter:
HTTP/2
HTTP/3
QUIC
HTTP/2 typically runs over TLS/TCP.
HTTP/3 uses QUIC over UDP.
This means a browser request that looks like:
HTTPS
might involve:
UDP
+
QUIC
+
TLS
+
HTTP/3
rather than:
TCP
+
TLS
+
HTTP/1.1
Wireshark’s broad protocol dissector ecosystem makes it useful for investigating these newer protocols as well. The official filter-reference and user-guide documentation cover supported protocol fields and analysis mechanisms. (Display Filter Reference; User’s Guide)
When HTTP/3 is involved, look beyond:
tcp
and investigate:
quic
or:
udp
The transport layer has changed.
This demonstrates an important troubleshooting principle:
Do not assume the protocol stack. Verify it from the capture.
Wireshark can support analysis of:
Latency
Retransmissions
Throughput
Windowing
Packet loss indicators
Connection setup
Protocol overhead
But it should not be used as the only performance tool.
Combine packet analysis with:
Application metrics
CPU
Memory
Storage
Network counters
Logs
This is especially important for production systems.
High-volume environments can generate very large captures.
A capture strategy should define:
Duration
Packet scope
File size
Rotation
Retention
Location
Access control
Instead of:
Capture everything forever
use:
Capture only what is needed
for the shortest useful period
This reduces storage and privacy risk.
For incident investigation, ring-buffer capture strategies can be useful.
Conceptually:
capture_01.pcapng
capture_02.pcapng
capture_03.pcapng
capture_04.pcapng
When the limit is reached:
oldest file
↓
replaced
This maintains a rolling window.
The exact configuration depends on the capture tool and environment.
When traffic is enormous, consider capturing only the required traffic.
For example:
tcp port 443
or:
host 192.168.1.10
or:
host 192.168.1.10 and port 443
This reduces noise and capture size.
But remember:
A restrictive capture filter can permanently exclude packets needed later.
Therefore define the investigative question before deciding how aggressively to filter.
When uncertain about what you need, it can be preferable to capture a sufficiently broad but controlled set and refine the view later using display filters.
For example:
Capture:
host 192.168.1.10
Then investigate later:
tcp
dns
tls
icmp
This provides more flexibility.
Wireshark can visually distinguish packet classes.
For example:
TCP
DNS
HTTP
Retransmissions
Errors
Coloring is useful for visual analysis, but it should never replace protocol interpretation.
A packet’s color is an aid to the analyst, not a diagnosis.
Instead of reading every field, start with:
Frame
Ethernet
IP
Transport
Application
Then expand only the fields relevant to your question.
For example, during TLS troubleshooting:
Ethernet
IP
TCP
TLS
may be enough.
There is no benefit in expanding unrelated fields simply because they exist.
The hexadecimal view is particularly useful when:
Unexpected parser behavior
Protocol debugging
Unknown payload
Malformed packets
Custom protocols
Raw field verification
The upper protocol dissection tells you:
What Wireshark believes the packet contains.
The bytes view tells you:
What bytes were actually captured.
That distinction is extremely useful when investigating parsing questions.
Wireshark may label packets or protocol structures as malformed.
Do not automatically conclude:
The sender transmitted an invalid packet.
Possible reasons include:
Capture truncation
Unsupported protocol feature
Dissector limitations
Corrupted capture
Actual malformed packet
Offload artifacts
Always inspect the full context.
Modern operating systems and NICs use hardware offloading.
As a result, packet captures taken on an endpoint can sometimes show checksum-related values that appear incorrect even though packets transmitted successfully.
Possible offloads include:
Checksum offload
TCP segmentation offload
Generic segmentation offload
Large receive offload
Therefore:
A checksum warning in an endpoint capture does not automatically prove a network fault.
This is one of the most important advanced concepts for beginners moving into serious packet analysis.
Suppose:
Application
↓
Host NIC
↓
Virtual switch
↓
Physical switch
A capture taken:
inside application host
may differ from one taken:
on switch mirror port
because of:
Offloading
NAT
Virtualization
Encryption
Encapsulation
Always record the capture point.
Network Address Translation changes addressing between network boundaries.
A packet may appear:
Inside:
10.0.0.10
and later:
Outside:
203.0.113.10
A capture taken on one side of the NAT device will not necessarily match a capture taken on the other side.
This is another reason capture location is essential to interpretation.
For broader NAT and network architecture concepts, see Computer Networking Explained.
Suppose an application uses:
Client
↓
Load Balancer
↓
Server A
Server B
Server C
Captures from different points can reveal:
Which backend received the request
Whether health checks are working
Whether connections are reset
Whether TLS terminates at the load balancer
For the broader architecture, see Cloud Load Balancing where applicable to your published cluster, alongside Cloud Networking Explained.
With Nginx or Apache, the packet path may be:
Client
↓
HTTPS
↓
Reverse Proxy
↓
HTTP / HTTPS
↓
Backend
A capture at the client-facing interface may show:
TLS
while a server-side capture may show:
HTTP
This is perfectly normal if TLS terminates at the proxy.
For REST APIs:
Client
↓
DNS
↓
TCP
↓
TLS
↓
HTTP
↓
API
Wireshark can help identify where the request stops.
For example:
DNS → OK
TCP → OK
TLS → OK
HTTP request → sent
HTTP response → 502
The network path is largely working.
Now investigate the proxy/backend relationship.
DevOps teams often troubleshoot:
CI/CD runners
Containers
APIs
Kubernetes nodes
Cloud VMs
Service-to-service traffic
Wireshark is especially valuable when application logs say:
Connection timeout
Connection reset
TLS error
DNS error
because the packet capture lets engineers determine which layer actually failed.
Container networking may involve:
Container
↓
Network namespace
↓
veth pair
↓
Bridge
↓
NAT
↓
Host
↓
Physical network
A capture taken inside the container may differ from one taken on the host.
This makes capture-point selection especially important.
Kubernetes introduces additional layers:
Pod
↓
veth
↓
CNI
↓
Node
↓
Service
↓
Load Balancer
Packet captures can help troubleshoot:
Pod-to-pod traffic
Service connectivity
DNS
Ingress
Network policies
External connectivity
But packet capture should be combined with Kubernetes-level inspection and metrics.
Packet captures can contain highly sensitive information.
They may include:
IP addresses
Hostnames
URLs
Application metadata
Cookies
Credentials
Personal data
Internal system information
Therefore:
Capture
↓
Protect
↓
Analyze
↓
Retain only when necessary
↓
Securely delete
Access to PCAP files should be treated as access to potentially sensitive operational data.
A PCAP may contain far more information than expected.
Do not casually upload a production capture containing:
Customer traffic
Authentication data
Internal addresses
API requests
Application data
to an untrusted online analyzer.
Use authorized internal tooling whenever sensitive traffic is involved.
A strong SOC workflow can be:
Alert
↓
Identify host
↓
Determine time window
↓
Locate capture point
↓
Acquire PCAP
↓
Hash / preserve evidence
↓
Analyze conversations
↓
Filter indicators
↓
Correlate with logs
↓
Determine scope
↓
Document findings
This connects packet analysis with the broader incident-response process.
Never capture blindly.
Ask:
What am I trying to prove?
Document:
Host
Interface
VLAN
Mirror port
Time
Location
Do not confuse capture filters and display filters.
Individual packets are often less useful than sequences.
Performance problems are often timing problems.
Use:
Logs
ss
ip
dig
curl
SIEM
Application metrics
Treat them as sensitive operational artifacts.
A retransmission is a clue.
A RST is a clue.
A DNS error is a clue.
Interpret the complete sequence.
| Objective | Display Filter |
|---|---|
| All TCP | tcp |
| All UDP | udp |
| All DNS | dns |
| All ICMP | icmp |
| All IPv6 | ipv6 |
| TCP 443 | tcp.port == 443 |
| Source IP | ip.src == 192.168.1.10 |
| Destination IP | ip.dst == 192.168.1.10 |
| Specific IP | ip.addr == 192.168.1.10 |
| DNS name | dns.qry.name == "example.com" |
| SYN | tcp.flags.syn == 1 |
| RST | tcp.flags.reset == 1 |
| FIN | tcp.flags.fin == 1 |
| Retransmission | tcp.analysis.retransmission |
| Duplicate ACK | tcp.analysis.duplicate_ack |
| Out of order | tcp.analysis.out_of_order |
| Zero window | tcp.analysis.zero_window |
| TLS | tls |
| HTTP | http |
| ARP | arp |
| TCP + IP | ip.addr == 192.168.1.10 && tcp |
| DNS or ICMP | `dns |
The syntax and available fields should be checked against the current Wireshark filter reference because supported protocol fields evolve between releases. (Wireshark Display Filter Reference)
| Objective | Capture Filter |
|---|---|
| TCP 443 | tcp port 443 |
| UDP 53 | udp port 53 |
| Host | host 192.168.1.10 |
| Network | net 192.168.1.0/24 |
| ICMP | icmp |
| TCP | tcp |
| UDP | udp |
| Host + port | host 192.168.1.10 and port 443 |
Capture filters use libpcap-style syntax and are different from Wireshark display filters. (Wireshark CaptureFilters)
List interfaces:
tshark -D
Capture:
tshark -i 1
Capture filter:
tshark -i 1 -f "tcp port 443"
Read PCAPNG:
tshark -r capture.pcapng
Display filter:
tshark -r capture.pcapng -Y "tcp"
Retransmissions:
tshark -r capture.pcapng -Y "tcp.analysis.retransmission"
The official TShark documentation defines these command-line capabilities and its relationship with Wireshark’s protocol-analysis engine. (TShark manual)
| Problem | First Filter | What to Examine |
|---|---|---|
| DNS failure | dns | Queries, responses, response codes |
| TCP timeout | tcp | SYN, SYN/ACK, retransmissions |
| Connection reset | tcp.flags.reset == 1 | Who sent RST and when |
| Slow application | tcp.analysis.retransmission | Loss, timing, windows |
| HTTP error | http | Request and response |
| TLS failure | tls | Handshake and alerts |
| Local connectivity | arp | Requests and replies |
| Ping failure | icmp | Echo request/reply |
| IPv6 issue | icmpv6 | Neighbor discovery, ICMPv6 |
| Unexpected connections | tcp / udp | Destination, ports, timing |
For a generic network problem:
USER REPORT
|
v
Define exact symptom
|
v
Choose capture point
|
v
Start controlled capture
|
v
Filter traffic
|
+-------------+-------------+
| | |
v v v
DNS TCP UDP
| | |
+-------------+-------------+
|
v
Application
|
v
Analyze timing
|
v
Follow streams
|
v
Identify divergence
|
v
Test hypothesis
|
v
Confirm root cause
This is the methodology that turns Wireshark from a packet viewer into an engineering tool.
| Feature | Wireshark | tcpdump | TShark |
|---|---|---|---|
| GUI | Yes | No | No |
| Packet capture | Yes | Yes | Yes |
| Deep protocol dissection | Excellent | More limited | Excellent |
| Display filters | Excellent | Not equivalent | Excellent |
| Automation | Moderate | Excellent | Excellent |
| Visual statistics | Excellent | Limited | Command-line |
| Best use | Deep interactive analysis | Lightweight capture | CLI analysis / automation |
A powerful Linux workflow is:
tcpdump / TShark
↓
Capture
↓
PCAPNG
↓
Wireshark
↓
Interactive analysis
A structured learning path is:
Networking Fundamentals
↓
Ethernet
↓
IP
↓
TCP / UDP
↓
DNS
↓
HTTP / HTTPS
↓
Wireshark Interface
↓
Capture Filters
↓
Display Filters
↓
TCP Handshake
↓
Retransmissions
↓
DNS Analysis
↓
TLS Analysis
↓
PCAP Analysis
↓
TShark
↓
Security Analysis
↓
Advanced Troubleshooting
This connects naturally with the existing CorgiNetwork networking material:
Wireshark captures and analyzes network packets and decodes protocols so engineers can troubleshoot networking, applications and security events.
No. Wireshark is primarily a packet capture and protocol-analysis tool.
Yes. Wireshark is an open-source network protocol analyzer distributed by the Wireshark project.
A PCAP file stores captured network packets for later analysis. Wireshark also supports PCAPNG, its native capture format. (TShark manual)
Capture filters restrict packets during capture. Display filters restrict which already captured packets are shown and analyzed. Their syntax is different. (Wireshark CaptureFilters)
Wireshark can dissect TLS metadata, but HTTPS application payloads remain encrypted unless appropriate decryption material and supported conditions are available.
If credentials are transmitted in plaintext and the relevant traffic is captured, packet analysis may expose them. Encrypted protocols generally prevent this without authorized decryption material.
Not automatically. On switched networks, you generally need the correct observation point such as a mirror/SPAN port or network TAP to see traffic not destined for your host. Wireshark’s FAQ explains the limitations of promiscuous mode on switched networks. (Wireshark FAQ)
TShark is Wireshark’s command-line protocol analyzer for live captures and saved capture files. (TShark manual)
Yes, when used in authorized environments. It can support analysis of suspicious connections, DNS activity, scanning behavior and protocol anomalies.
No. Wireshark is primarily a packet-analysis tool. Monitoring systems provide broader long-term metrics, alerting and operational dashboards.
No. They serve overlapping but different roles. tcpdump is lightweight and excellent for capture, while Wireshark provides a richer interactive analysis environment.
Understanding Ethernet, IP, TCP/UDP, DNS and basic network troubleshooting makes Wireshark dramatically easier to use.
A useful way to think about Wireshark is:
PACKET
|
v
FRAME LAYER
|
v
NETWORK LAYER
|
v
TRANSPORT LAYER
|
v
APPLICATION LAYER
|
v
PROTOCOL FIELDS
|
v
FILTER
|
v
SEQUENCE
|
v
TIMING
|
v
HYPOTHESIS
|
v
EVIDENCE
|
v
ROOT CAUSE
The important transition is:
Packet → Evidence → Explanation
rather than:
Packet → Guess
Wireshark is much more than a graphical packet viewer.
It is a detailed network-analysis platform that allows engineers to inspect communications from Ethernet frames through IP, TCP/UDP and application protocols.
Its strongest capabilities include:
Packet capture
Protocol dissection
Display filters
Capture filters
TCP analysis
DNS analysis
TLS analysis
PCAP/PCAPNG
Conversation analysis
Statistics
TShark
Security investigation
Troubleshooting
The distinction between capture filters and display filters is foundational. Capture filters use libpcap-style syntax to control what is captured, while display filters use Wireshark’s own filtering language to control what is displayed and analyzed after capture. (Wireshark CaptureFilters; wireshark-filter)
Wireshark’s display-filter engine is particularly powerful: the official reference currently contains a very large collection of protocol fields that can be used for detailed packet selection and analysis. (Display Filter Reference)
The most valuable skill is not memorizing hundreds of filters.
It is learning to move systematically through the communication:
DNS
↓
TCP / UDP
↓
TLS
↓
HTTP / Application
and ask:
What was supposed to happen?
What actually happened?
Where did the sequence diverge?
What evidence proves it?
That methodology allows Wireshark to solve real problems such as:
DNS failures
TCP timeouts
Retransmissions
Connection resets
TLS negotiation failures
HTTP errors
Packet loss
Routing problems
ARP failures
Performance degradation
Suspicious network activity
For Linux engineers, Wireshark becomes even more powerful when combined with:
ip
ss
dig
curl
tcpdump
and with the networking foundations covered in Computer Networking Explained, TCP/IP Explained, DNS Explained, Firewalls Explained, VPNs Explained, Network Security Basics, and Linux Server Administration.
The next logical article in the Tools & Software cluster is:
Nmap Explained: Network Discovery, Port Scanning, Service Detection, OS Detection, NSE Scripts and Defensive Security
which will complement Wireshark perfectly:
Nmap
↓
What is exposed?
Wireshark
↓
What is actually happening on the network?
Together, they form two complementary tools for serious network administration and security analysis.
AI Agents as Code: Managing AI Agent Configurations, Prompts and Tools with Git AI agents…
Data Center Power Distribution Architecture: UPS, PDU, Redundancy and Rack Power Explained Data center power…
DNSSEC Troubleshooting: Fix SERVFAIL & DNSKEY Errors DNSSEC Troubleshooting: How to Fix SERVFAIL, DS, DNSKEY…
Terraform State Management Explained: Remote State, Locking, Backends and Best Practices Terraform makes infrastructure reproducible…
RTO vs RPO Explained: Disaster Recovery Objectives, Examples and Planning A disaster recovery plan is…
Network Intrusion Detection Explained: NIDS, Sensors, Signatures and Traffic Analysis A firewall can decide whether…