A tutorial on the tcpdump command in Linux

A tcpdump line can be hard to interpret when you do not know what its fields mean. tcpdump prints packet summaries with the time, protocol, endpoints and other decoded fields.

This tutorial explains how to read those fields and decode TCP flags and sequence numbers.

TL;DR: Read tcpdump output from left to right

A tcpdump line identifies when a packet appeared, its protocol and endpoints, then fields such as TCP flags and data length. Read direction before interpreting protocol details.

• Use -nn to keep addresses and ports numeric.
• Use -r capture.pcap to inspect a saved capture without opening a live interface.
• Use -X for a hexadecimal and ASCII view when packet data is present.

What is tcpdump output?

tcpdump output describes packets matching a capture filter. It decodes packet headers into fields rather than printing raw bytes.

tcpdump reads live traffic from an interface or decodes packets saved in a file. It prints a compact header summary by default, with fields determined by protocol and options.

Limit a busy trace before reading it. The libpcap filter reference documents host, network, port and protocol qualifiers. Filters select packets before printing, so an omitted packet may not match the expression.

How to read tcpdump output step by step

Each packet line starts with time, then protocol, endpoints and protocol fields. The next steps show how to choose traffic, parse a line, and inspect a saved trace.

Step 1: Choose the interface and limit the capture

List interfaces with tcpdump -D and select the one that carries the traffic you want. On Linux, any captures available interfaces, but a specific interface can clarify direction and duplicate observations.

sudo tcpdump -nn -i any -c 20 'host 192.0.2.10 and tcp port 443'

The command keeps endpoints numeric, selects the interface with -i, and stops after -c packets. Its filter matches TCP port 443 to or from the example host.

Replace the example address with the endpoint you are investigating. Add src host or dst host to follow one direction.

Capture may need elevated privileges or a configured packet-capture capability. Use the least privilege available, and protect saved files because they may contain sensitive traffic.

Step 2: Read each packet line from left to right

A TCP summary typically puts a timestamp first, followed by IP endpoints and TCP-specific fields.

#!/usr/bin/env bash
set -euo pipefail
capture_file="tcpdump-demo-output.txt"
python3 -m http.server 18080 --bind 127.0.0.1 >/dev/null 2>&1 &
server_pid=$!
cleanup() {
  kill "$server_pid" 2>/dev/null || true
  wait "$server_pid" 2>/dev/null || true
  rm -f "$capture_file"
}
trap cleanup EXIT
sleep 1
sudo tcpdump -nn -i lo -c 4 'tcp port 18080' >"$capture_file" 2>&1 &
capture_pid=$!
for attempt in {1..50}; do
  if [[ -f "$capture_file" && "$(<"$capture_file")" == *'listening on lo'* ]]; then
    break
  fi
  sleep 0.1
done
curl --silent --output /dev/null http://127.0.0.1:18080/
wait "$capture_pid"
printf '%s\n' "$(<"$capture_file")"

The script starts a local HTTP server and captures one loopback request.

bash tcpdump_read_demo.sh

aprataksh@linuxfordevices:~$ bash tcpdump_read_demo.sh
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:27:11.121491 IP 127.0.0.1.54122 > 127.0.0.1.18080: Flags [S], seq 3559096898, win 65495, options [mss 65495,sackOK,TS val 451779916 ecr 0,nop,wscale 10], length 0
22:27:11.121506 IP 127.0.0.1.18080 > 127.0.0.1.54122: Flags [S.], seq 202591410, ack 3559096899, win 65483, options [mss 65495,sackOK,TS val 451779916 ecr 451779916,nop,wscale 10], length 0
22:27:11.121518 IP 127.0.0.1.54122 > 127.0.0.1.18080: Flags [.], ack 1, win 64, options [nop,nop,TS val 451779916 ecr 451779916], length 0
22:27:11.121583 IP 127.0.0.1.54122 > 127.0.0.1.18080: Flags [P.], seq 1:79, ack 1, win 64, options [nop,nop,TS val 451779916 ecr 451779916], length 78
4 packets captured
26 packets received by filter
0 packets dropped by kernel

[exit 0]

The timestamp precedes source and destination endpoints. Flags show the TCP handshake followed by a packet carrying data.

The arrow points from source to destination. Name lookups can hide numeric addresses, so -nn helps when comparing packets. Add -e to print link-layer details such as Ethernet addresses when available.

Without -nn, a numeric port can appear as a service name. That label is a lookup, not proof of the application.

Step 3: Decode TCP flags and sequence numbers

TCP flags describe connection and data-transfer state. tcpdump uses compact letters in brackets, so look for the combination rather than treating one character as a complete diagnosis.

• [S] marks SYN, used to begin a TCP connection.
• [S.] marks SYN plus ACK, commonly the server’s response during connection setup.
• [.] marks ACK with no other displayed flag.
• [P.] marks PSH plus ACK, often shown with application data.
• [F.] marks FIN plus ACK, used when a side closes its sending direction.
• [R] or [R.] indicates reset, which rejects or aborts a connection.

SYN, SYN-ACK and ACK form the familiar TCP opening exchange. A lone SYN does not prove a service is down, because the capture may end before a reply or use the wrong interface. A reset after SYN is a different signal from silence.

Sequence numbers mark positions in the TCP byte stream. ACK gives the next sequence number expected from the peer.

Relative 1:149(148) represents 148 sequence-space bytes, not every byte in the IP packet. An ACK-only segment can carry no data.

The win field is the receive window advertised by the sender. Compare it across packets in the same flow, rather than treating the value as a direct measure of an application’s buffer.

Step 4: Read a saved pcap file

A pcap file stores captured packets for later inspection. Write a bounded capture with -w, then read it with -r. Live interface access is not needed to decode an existing file, though file permissions still determine whether your account can open it.

sudo tcpdump -i any -nn -c 100 -w capture.pcap 'host 192.0.2.10'
tcpdump -nn -r capture.pcap

The capture file contains only packets recorded under the original interface, filter and snapshot length.

Keep those settings with the file so another reader can see why a packet is absent.

Step 5: Inspect packet contents when the capture includes them

Use -A for printable ASCII or -X for hexadecimal bytes alongside ASCII. These display options reveal captured payload bytes where tcpdump can decode them, but they do not decrypt encrypted application data.

sudo tcpdump -nn -i any -c 10 -X 'tcp port 80'

HTTPS payload normally appears as encrypted TLS records, not readable page text. DNS or a TLS handshake may expose a domain, but packet display is not a reliable search for every URL.

HTTP/2 and HTTP/3 can distribute an application message across packets. Byte inspection does not replace protocol-aware analysis.

To inspect more of a packet, tcpdump’s snapshot-length option controls how many bytes are captured from each packet. Increasing it can include more payload, but it also increases capture size and the amount of sensitive data collected. Check the tcpdump manual for option details.

Edge cases that make tcpdump output confusing

Output can look empty or incomplete even when the application has a problem, because tcpdump sees only traffic visible at its capture point and within its filter. Check the interface and capture summary before drawing conclusions from a missing line. Capture visibility is not the same as end-to-end reachability.

• No packets appear: confirm the interface with tcpdump -D, verify the host or port filter, and check whether the traffic actually crosses that machine. Try a short capture on the intended interface rather than assuming any sees every namespace or remote link.
• Names obscure endpoints: use -nn to stop address and service-name lookups. This also helps separate a numeric port from a service label.
• Payload looks truncated: a capture snapshot length may have limited bytes, or the packet may contain encrypted data. The printed payload length is not proof that the complete application message was captured.
• Packets dropped by kernel: check the final capture statistics. The kernel-drop count reflects packets lost by the capture mechanism when buffer space was insufficient, where the operating system reports that figure. It is distinct from packets that your filter intentionally excluded.
• Output is too busy: add a host, port or protocol filter and a packet count. Filter expressions combine terms with and, or and not. Use parentheses or quoting when shell parsing could alter the expression.

A capture summary reports packets captured, packets received by filter and packets dropped by kernel. The exact meaning of received-by-filter varies with the operating system and capture setup, so do not treat it as a portable count of packets matching your expression. Stop an unbounded capture with Ctrl+C to see its final summary.

A zero kernel-drop count means that interface reported no drops. It does not prove every network packet was visible, since capture point, interface and filters limit what reaches tcpdump.

Compare endpoints and ports with listening sockets, then test a connection with netcat. Use the traceroute command when the route needs inspection.

Conclusion: Start with the endpoints, then decode the fields

Read tcpdump output in order: timestamp, protocol, endpoints, then protocol fields. Filters focus the trace, but they cannot restore bytes that were not captured or decrypt payloads.

For related diagnosis, see how to check listening ports, change DNS settings on Linux, and use the Ubuntu network configuration guide. For exact field and option definitions, consult the tcpdump manual.