Reading a Wireshark capture means narrowing thousands of packets down to the handful that answer your question. The window gives you a packet list, a decoded tree for the selected packet, and the raw bytes. Almost all of the skill is in the display filter bar above them.
- Start with a question a capture can settle, not with the file
- Statistics, Conversations usually names your filter for you
- Display filters and capture filters are different syntaxes
- Black rows with red text are the first ones to open
- A switch port shows you your own traffic and nothing else
On this page
The three panesWhat you are actually looking at
Reading a Wireshark capture starts with knowing what is on the screen. The window is three panes stacked, and each one shows the same captured packet at a different level of detail.
The packet list, at the top. One row per packet, with a number, a timestamp, the source address, the destination address, the protocol Wireshark decided it is, the length in bytes, and a summary line.
This pane is where you spend most of your time, and the information in the summary column goes further than people expect: for TCP it shows the flags, the sequence number, and the window size, which is often the whole answer.
The packet details, in the middle. Select a packet in the list and this pane decodes it into a tree, one network layer per line, from the frame as captured through Ethernet, IP, the transport protocol, and the application protocol on top.
Expanding a layer shows every field with its decoded value: the MAC addresses at the Ethernet layer, the IP addresses above them, the ports above those. This is the pane that teaches you protocols, because it labels bytes you would otherwise have to look up.
The packet bytes, at the bottom. The same captured data as raw hexadecimal with an ASCII column beside it. Click a field in the middle pane and Wireshark highlights the bytes it came from.
You need this pane less often than the other two, and it is the one to reach for when Wireshark has decoded something as an unknown protocol and you want to see what data is really there.
Above all three sits the display filter bar, which is the part that matters. Everything below it is a view of whatever your filters let through.
Where to startThe first five minutes of any capture
A capture file is not a document to read from top to bottom. It is a database of network data to query, and the queries go in a rough order.
Start with a question you could answer yes or no. "Did the client ever get a DNS answer for that name" is a question a capture can settle, and DNS is one of the easiest protocols to prove or rule out.
"Why is the application slow" is not, at least not directly, and starting there is how people end up scrolling through fifty thousand rows.
Check Statistics, Capture File Properties. Its output tells you the time span, the packet count, and the average rate. A capture that covers four seconds cannot explain a problem the user says happens every few minutes.
Open Statistics, Conversations. This sorts every pair of endpoints by bytes and packets exchanged. The conversation you care about is usually visible in the first few rows, and the source and destination pair you find there becomes your filter.
Set the time display to something you can reason about. View, then Time Display Format, then select a format. Seconds since the beginning of the capture is the default and it is fine for measuring gaps. Select time of day instead when you need to line the capture up against log information or a user saying it broke at 10:42.
Then filter, and keep filtering. Each filter should remove traffic you have ruled out. When roughly a screen of packets is left, start reading them rather than filtering further.
FiltersDisplay filters worth memorizing
Display filters use field names and comparisons, and the same handful of filters covers most work. Wireshark turns the bar green when the expression parses and red when it does not, which is the fastest syntax check there is.
| Filter | What it shows |
|---|---|
| ip.addr == 10.0.5.20 | Every packet to or from that host |
| ip.src == 10.0.5.20 && ip.dst == 8.8.8.8 | One direction only, between two hosts |
| tcp.port == 443 | Traffic on a port, in both directions |
| dns | Every DNS query and response |
| http.request | Requests only, without the responses and the packets carrying them |
| tcp.flags.syn == 1 && tcp.flags.ack == 0 | Connection attempts, which is where failures start |
| tcp.analysis.retransmission | Packets Wireshark believes were sent again |
| tcp.analysis.flags | Every condition Wireshark flagged as worth noticing |
| frame contains "password" | A byte string anywhere in the packet |
| !(arp || stp || cdp) | Everything except the background chatter |
Two notes that save a lot of confusion.
Display filters are not capture filters. The bar at the top of the Wireshark window uses display filter syntax, ip.addr == 10.0.5.20. The field you fill in before starting a capture uses Berkeley Packet Filter syntax instead, host 10.0.5.20.
The two kinds of filters look similar, they are not interchangeable, and typing one where the other belongs is the single most common beginner mistake.
Right click, then Apply as Filter. You rarely need to type field names. Find a field in the details pane, right click it, and Wireshark writes the filter expression for you. Click through a few packets that way and you learn the field names, which is worth more than memorizing them.
Worked exampleReading a TCP handshake, and what failure looks like
Most connection problems are visible in the first three packets, and knowing what a healthy exchange looks like makes the broken ones obvious.
A working connection opens with three packets in a row: a SYN from the client, a SYN plus ACK from the server, and an ACK from the client. In the packet list they appear within a millisecond or two of each other on a local network, and the source, the destination and the flags are all in the summary output.
No. Time Source Destination Proto Info
41 0.000000 10.0.5.20 10.0.9.8 TCP [SYN] Seq=0 Win=64240
42 0.000318 10.0.9.8 10.0.5.20 TCP [SYN, ACK] Seq=0 Ack=1
43 0.000401 10.0.5.20 10.0.9.8 TCP [ACK] Seq=1 Ack=1The failures each look different, and each one names a different cause.
SYN, then nothing. The client sends a SYN and repeats it a few seconds later, and no answer comes back at all.
Something on the network dropped the packet silently, which is what a security device configured to drop rather than reject does. Nothing is wrong with the server from the client's point of view, because the client never reached it.
SYN, then RST, ACK. The server answered, and the answer was a refusal. That means the packet arrived at a host that is up and has nothing listening on that port. This is a service that is down or bound to the wrong address, not a network problem.
SYN, then ICMP destination unreachable. A router along the path told the client it could not deliver the packet. The ICMP message names which router and why, and that is the routing answer handed to you.
A handshake that completes, then a long gap. The connection is fine and the application on top is slow. Look at the time column between the request and the first byte of response data, because that gap is the server thinking, not the network moving.
The same reading applies further into a conversation. A run of retransmissions with growing gaps between them means packets are being lost somewhere on the network. A window size falling toward zero means the receiver cannot keep up with the data arriving and is telling the sender to wait, which is a host problem, not a link problem.
Coloring rulesWhat the colors mean
Wireshark colors rows in the packet list using an ordered rule list, and the first rule that matches wins. The defaults are worth knowing because they are the fastest triage available.
| Row color | What matched | Worth a look |
|---|---|---|
| Black background, red text | Wireshark's TCP analysis flagged it | Yes, first |
| Light purple | Ordinary TCP traffic | No |
| Pale blue | Ordinary UDP traffic | No |
| Green | HTTP | Only for the request you are chasing |
| Yellow | Usually a routing protocol or a window update | Sometimes |
| Gray | Checksum errors | Almost never |
Black background with red text is the one that matters. It means Wireshark's TCP analysis flagged the packet: a retransmission, a duplicate acknowledgment, an out of order segment, or a reset. Black rows scattered through a capture are the first thing to look at.
Gray means checksum errors, and these are almost always false. Modern network cards compute checksums in hardware after the packet leaves the capture point, so an outbound packet is captured before its checksum exists. Turn checksum validation off in the TCP protocol preferences and the noise disappears.
Colors are a hint rather than a verdict. A capture full of black rows on a wireless network is normal, and a capture with none can still be showing you a serious problem.
Capture pointCapturing the right traffic in the first place
A capture that does not contain the traffic you need cannot be read no matter how good the filters are, and this is where most wasted afternoons come from.
A switch does not send you other people's data. A capture taken on a laptop plugged into a switch port shows that laptop's traffic and broadcasts, and nothing else.
To see traffic between two other machines you need a mirror port on the switch, sometimes called a SPAN, or a network tap on the cable. This is also why network security tools that inspect traffic are fed from a tap or a mirror rather than from an ordinary port.
Capture on the machine with the problem. When the question is about one client, the capture belongs on that client. It is the one place where you see what it actually sent, before anything on the path had a chance to change it.
Capture at both ends when packets go missing. One capture proves a packet was sent. Two prove whether it arrived, and the difference between them names the segment where it disappeared.
Use capture filters when the network interface is busy. Display filters hide packets after they are written to disk; capture filters stop them from being written at all. On a busy link, host 10.0.5.20 in the capture filter is the difference between a manageable file and forty gigabytes of data.
Encrypted traffic stays encrypted. You will see the TLS handshake, the certificate the server presented, the names inside it, and the size and timing of everything after that. You will not see the data itself without the session keys, and no filter changes that. That property is the security guarantee working as designed, not a limitation of Wireshark.
PitfallsWhere people go wrong
Reading top to bottom. A capture is queried, not read. Anyone scrolling through a packet list looking for something wrong is spending time the filter bar would have saved.
Trusting the protocol column. Wireshark guesses the protocol from the port number and the shape of the bytes, so that column is a suggestion rather than information from the packet itself. A service on a nonstandard port is often labeled as something else entirely, and right clicking to Decode As is the fix.
Chasing checksum errors. Almost always an artifact of hardware offload on the capturing machine rather than a real corrupted packet.
Treating every retransmission as the fault. Some retransmission is normal, especially over wireless or long paths. The signal is a change in rate, or retransmissions clustered around the moment the user says the problem happened.
Confusing capture filter syntax with display filter syntax. host 10.0.5.20 in the display bar turns it red, and ip.addr == 10.0.5.20 as a capture filter refuses to start.
Forgetting the capture point. Every capture is taken somewhere, and the answer is often about that somewhere. A packet missing from a capture taken on a switch port may have been sent perfectly and simply never mirrored to you.
Capturing without a question. The most common failure, and the reason so many pcap files are opened once and never used.
ComparisonThe three tools, and which one belongs at which step
| Criterion | Wireshark | tshark | tcpdump |
|---|---|---|---|
| Interface | Graphical | Command line | Command line |
| Reads pcapng | Yes | Yes | Partly |
| Full protocol decoding | Yes | Yes | Limited |
| Runs over SSH on a server | No | Yes | Yes |
| Installed on most Linux hosts | No | No | Yes |
| Display filter syntax | Yes | Yes | No, BPF only |
| Practical on a huge file | No | Yes | Yes |
The usual pattern is to run tcpdump on whichever Linux machine has the problem, because that tool is already installed there, and then copy the file back and read it in Wireshark. Each tool has its place: tcpdump collects, tshark filters a file too large to open, and Wireshark is where you read what is left.
FAQFrequently asked questions
What file format does Wireshark use?
pcapng, which replaced the older pcap format. Wireshark reads both, along with capture files from dozens of other tools, so a file from tcpdump opens without conversion.
What is the difference between a capture filter and a display filter?
A capture filter decides what gets written to the file and uses BPF syntax such as host 10.0.5.20. A display filter decides what you see in an already captured file and uses Wireshark's own syntax, ip.addr == 10.0.5.20.
Why is my capture only showing my own traffic?
Because a switch forwards traffic only to the port it belongs to. To see traffic between other machines you need a mirror port on the switch or a tap on the cable.
What do the black rows with red text mean?
Wireshark's TCP analysis flagged something: a retransmission, a duplicate acknowledgment, an out of order segment, or a reset. They are the first rows worth looking at.
Why do I see checksum errors on my own outgoing packets?
Because the network card computes the checksum in hardware after the packet was captured. Turn checksum validation off in the TCP preferences and the false errors disappear.
Can I read HTTPS traffic in Wireshark?
Not the contents, without the session keys. You will see the handshake, the server's certificate and the hostname it names, and the timing and size of everything after that.
How do I find a slow server in a capture?
Filter to the conversation, then read the time column between the request and the first byte of the response. A long gap after a healthy handshake is the application thinking rather than the network moving.
What does a RST packet mean?
The other end refused or tore down the connection. A reset immediately after a SYN means nothing is listening on that port, and a reset in the middle of a conversation means one side gave up.
How large a capture can Wireshark open?
A few hundred megabytes is comfortable and a gigabyte is painful. For anything larger, filter it down first with tshark or editcap and open the result.
How do I capture without filling the disk?
Use a ring buffer. In the capture options, set multiple files with a size or time limit, and Wireshark keeps only the most recent ones while the problem you are waiting for happens.
Do I need administrator rights to capture?
Yes on Windows, where the driver requires it, and normally yes on Linux and macOS unless the capture privileges have been delegated to a group.
Is running Wireshark on a company network allowed?
Ask first. Capturing traffic you are not responsible for is a policy question and often a legal one, and the answer differs by organization and by country.
Keep readingRelated concepts
Read next · Ports What Is a Port Number? Wireshark guesses the protocol from the port, which is why a service on a nonstandard port gets labeled wrong. Open this next12 min- Diagnostics · 11 min Ping and Traceroute Both tools answer the question a capture is often opened to settle, and they answer it in seconds.
- Protocols · 11 min What Is ICMP? A destination unreachable message in a capture names the router that could not deliver, which is the routing answer handed to you.
- Diagnostics · 11 min CRC Errors, and the Four Moves That Find the Cause CRC errors, and why the counter climbs while a capture of the same link shows nothing.
- Protocols · 10 min PTP, NTP, and Why a Clock Breaks Authentication First Where wrong clocks show up next.
- Protocols · 9 min Telnet, Why SSH Replaced It, and the One Job It Kept How to see a session for yourself.
- Protocols · 10 min The TCP Header, Field by Field, and What to Read in a Capture Where to read all of this in practice.
- Fundamentals · 10 min The IPv4 Header, Field by Field and in Order of Usefulness Where to see this header with real values in it.