pjhtech Tools
Network tools · Network tools

tcpdump Filter Examples for Everyday Network Troubleshooting

Start a tcpdump investigation with one question: which packet should appear at this capture point? A narrow question produces a useful trace. A broad capture on a busy gateway often produces a large file without explaining the failing connection.

Scope: tcpdump with libpcap on Linux; interface names vary. Capture requires permission. Reading a saved PCAP does not generate network traffic.

These examples use eth0 and 192.0.2.20 as placeholders. Replace both. Capturing observes traffic and consumes resources. It does not edit firewall rules or persistent network configuration, but tcpdump can temporarily request promiscuous mode on the selected interface. Use -p when promiscuous capture is unnecessary. Capture only traffic you are authorized to inspect, because payloads and application metadata may be sensitive.

Start with a bounded capture #

Start with a bounded capture
Network tools · Local shell; platform and privileges as described below

Read-only
tcpdump -D
Output may contain sensitive operational data.
Diagnostic state

Replace these example values: eth0, 192.0.2.20.

sudo tcpdump -ni eth0 -c 100 'host 192.0.2.20'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Diagnostic state

Replace these example values: eth0, 192.0.2.20.

sudo tcpdump -ni eth0 -c 100 'host 192.0.2.20 and tcp port 443'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

The first command lists capture interfaces. Numeric output avoids name and service lookups. The packet count stops the capture after 100 matching packets; on a quiet link it can still wait indefinitely, so use Ctrl-C when the test finishes. Confirm the selected interface actually carries the flow before interpreting an empty result.

Filters by question #

QuestionCapture expression
Either direction for one IPv4 hosthost 192.0.2.20
Requests from that hostsrc host 192.0.2.20
Traffic involving a subnetnet 192.0.2.0/24
Conventional DNS over UDP or TCPport 53
HTTPS over TCP or QUIC's usual UDP portport 443
Either of two application portstcp and (port 443 or port 8443)
ICMP for IPv4 or IPv6icmp or icmp6
One IPv6 hostip6 and host 2001:db8::20

Quote the expression so the shell does not interpret parentheses. DNS over HTTPS will not appear in a port-53 capture. A port number identifies candidate traffic, not proof of the application inside it.

Save evidence for Wireshark #

Save evidence for Wireshark
Network tools · Local shell; platform and privileges as described below

Writes a file

Replace these example values: eth0, case.pcap, 192.0.2.20.

sudo tcpdump -ni eth0 -s 0 -c 1000 -w case.pcap 'host 192.0.2.20'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Read-only

Replace these example values: case.pcap.

tcpdump -nn -r case.pcap 'tcp port 443'
Output may contain sensitive operational data.

The first command writes a capture file; the second reads and filters it. A saved capture can be inspected repeatedly without reproducing the incident. Record the test time, interface, source, destination and expected path alongside the file.

Interpret without overclaiming #

An outbound request with no visible reply narrows the fault but does not identify the dropping device. Asymmetric routing, the wrong capture interface or an incomplete mirror session can hide replies. Collect a second capture nearer the destination when needed. Check tcpdump's dropped-packet summary before treating the trace as complete. Finally, confirm the real application succeeds; seeing a handshake alone is not an end-to-end test.

Sources

Documentation reviewed: 8 October 2026