Packet Analysis Guide (Wireshark & tcpdump)

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A capture is a copy of packets, and it is sensitive

A packet capture is a copy of what was on the wire or in a host's stack. It can contain names, cookies, and anything an application sent without encryption. Treat the file like a password file. Do not attach it to a public ticket, do not commit it, and do not leave it on a laptop longer than the incident. Delete it when the lesson is written down.

Ethernet frames, IP packets, and TCP segments are layers of the same event. A display filter that shows TCP does not mean the Ethernet header was absent. It means you asked the tool to focus. Start with the question. A question about a name is DNS. A question about a connection is the handshake. A question about slowness is timing and retransmissions, not a hunt through every packet.

This guide does not provide attacks, exploit payloads, or instructions for intercepting someone else's traffic. Capture on a network you operate, or on a host you were asked to diagnose, with the consent your organisation already requires. The analysers linked here read a file you paste or build a display filter. They do not sniff a remote network for you.

Encryption means the capture shows the handshake and the sizes, not the page the user loaded. That is a success of the encryption. Do not weaken it so a capture is easier. If you need the URL, look at the proxy or the application log that is supposed to record it.

A TCP connection in the order it happens

The client sends a SYN to the server's address and port. If you do not see it, the client did not send, or you are capturing on the wrong place. If you see the SYN and no reply, the server or the path dropped it. A SYN-ACK means the server accepted the attempt. The client's ACK completes the handshake. Only then does application data belong.

A reset is a refusal or an abort. It is different from silence. Silence is a filter, a blackhole, or a capture in the wrong place. A reset is someone answering no. Write which one you saw. The ticket changes. Retrying the application does not tell you which one it was.

Retransmissions mean something was not acknowledged in time. One retransmission can be normal. A field of them means loss or a full queue. They are not a reason to disable the firewall before you know which direction was lost. Note the direction. Loss toward the server and loss toward the client are different faults.

DNS before the handshake is its own conversation. If the name never resolves, you will not see a SYN to the right address, and the capture of the server will be empty. That empty capture is not proof the server is down. Capture at the client, or look at the resolver, before you blame the service.

TLS starts after TCP. A failure during the certificate exchange is a name, a clock, a trust store, or a middlebox. The TCP handshake can be perfect and the user still sees an error. Do not file that as a routing incident. File the alert the client showed.

UDP does not handshake. DNS, some voice, and some VPN traffic will look like requests and replies or like a one-way stream. Absence of a SYN is not a fault for UDP. Check you filtered for the right protocol before you call the service dead.

Where you capture changes what you can see

On the client you see what the client sent and what it received. You do not see a packet that died further along the path. On the server you see what arrived. A packet present at the client and absent at the server was dropped in between. A packet present at both was delivered, and the fault is the application or the reply.

A switch mirror copies a port to another port. It copies what that port saw, including the direction you selected. It does not create packets and it is not a tap of the whole company. Mirror the port in the ticket, not a trunk full of other people's traffic, unless that trunk is the question and you are allowed to hold that traffic.

Capturing on a busy core fills a disk and drops packets from the capture itself. A capture that dropped packets can hide the retransmission you were looking for. Prefer a short capture with a filter for the host you care about. Five minutes of one host beats an hour of a core you cannot open.

Time synchronisation matters when you compare two captures. If the client and the server disagree by minutes, you will invent a delay. Sync the clocks or note the offset. Write the filter you used so someone can repeat it. A filter of tcp.port == 443 is a start. A filter that also names the host is a diagnosis.

Filters that match the question

A display filter is a question to a file you already have. It is not a capture filter, and it is not a probe. tcp.port == 443 shows TCP port 443 in the file. It does not find malice. It finds a port. dns shows name lookups. icmp shows pings. A filter that names an address shows that address. Start there. Add conditions only when the first filter produced too much of the thing you already understand.

If the handshake is the question, look for the SYN and the SYN-ACK from the client and server addresses you wrote down. If the file has neither, you captured the wrong place or the wrong time. Do not invent a more clever filter to compensate for a capture that missed the event. Reproduce once more, with the filter ready, for a shorter time.

Exclude your own management traffic if it drowns the file, and say that you did. A capture of your SSH session to the switch is not the user's problem. It is also a secret, because it can contain keystrokes if the session was not what you thought. This is another reason the file does not go in the public ticket.

The builder on this site helps you spell a display filter. Paste the filter into the analyser you already use on the file you already have. The page does not fetch a capture from the network. If the filter returns nothing, the event is absent from the file. That is data. Save the sentence.

A disciplined look at one failure

Write the client address, the server address, the port, and the time. Start a short capture at the client. Reproduce once. Stop the capture. Look for the DNS answer, then the SYN, then the SYN-ACK, then data or an error. Stop at the first missing piece. That piece is the layer. Do not keep scrolling until you find something interesting.

If the SYN is missing, the client or its route is the question. If the SYN is present and the SYN-ACK is not, the path or the server is the question, and a capture at the server distinguishes them. If the handshake finishes and the application errors, leave the network ticket and take the error text to the application owner, along with the fact that the connection was established.

Save the conclusion, not the whole file, in the ticket. The conclusion is the sentence: the client sent a SYN to 203.0.113.10 port 443 and no SYN-ACK returned within the capture. That sentence is useful. The file is radioactive. Store it only where your incident process allows, and for as short a time as that process allows.

The display-filter builder on this site helps you write a filter. It does not capture. The paste analyser helps you look at text you already have. Neither one is a warrant to mirror a network you do not run.

Name the client, the server, the port, and the time.
Capture shortly, at the client, while you reproduce once.
Find DNS, then SYN, then SYN-ACK, and stop at the first gap.
Move the capture only if you need to see whether the packet arrived.
Write the sentence, not a novel.
Protect or delete the file according to your incident rules.

Mistakes that leak data or waste the window

Attaching a capture to a public ticket or a chat room.

Capturing a core for an hour with no filter.

Calling a TLS error a routing failure after the handshake succeeded.

Ignoring DNS because you filtered only for the IP you hoped to see.

Treating UDP as broken TCP because there was no SYN.

Comparing captures whose clocks differ by minutes.

Mirroring a trunk full of other users to debug one printer.

Keeping the file after the sentence is written.

Capture checks before you start

Confirm this before you call the change done: You are allowed to capture this network or this host. The filter names the host or the port so the file stays small. Clocks are close enough to compare if you will use two capture points. The ticket names client, server, and port. You know whether the protocol is TCP or UDP. A successful handshake will send you to the application error, not to a core reboot. The file has a place to live that is not a public system, and a time to be deleted. A display filter was written down so the look can be repeated. Documentation addresses in examples were replaced if you moved the notes into a real ticket. You did not weaken encryption to make the capture easier to read. The first missing piece, DNS or SYN or SYN-ACK, is the sentence in the ticket. A reset was recorded as a reset, and silence was recorded as silence. The capture point is the client, the server, or a named mirror, not an unnamed core. Management sessions were kept out of the file or the file was treated as a secret. The display filter is written next to the conclusion so it can be repeated. The file's deletion time is written next to its location. And a second person can repeat the display filter from the ticket alone. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.