---
{
  "title": "tcpdump",
  "summary": "Capture or inspect packets from a command-line environment.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "Wireshark User’s Guide",
      "url": "https://www.wireshark.org/docs/wsug_html_chunked/"
    },
    {
      "title": "The tcpdump project: maintained manual source",
      "url": "https://github.com/the-tcpdump-group/tcpdump/blob/master/tcpdump.1.in"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

tcpdump is a command-line packet capture and inspection tool. It supports capture expressions and can write packets for later analysis. Collection requires suitable authorization and privileges, and the chosen interface and filter determine visibility. Set a controlled output location and manage file size, retention, and sensitive data. The printed summary does not replace the underlying capture when detailed analysis is needed.

## In practice

A team collects a limited approved troubleshooting capture on the relevant interface and later examines the stored file in Wireshark.

## A common misunderstanding

Collecting on the wrong interface or with an overly narrow filter can produce a misleadingly empty result.

## Check your understanding

What should be agreed before a capture?

**Think it through:** Purpose, scope, interface, filter, duration, storage controls, and who may access the resulting data.


## Capture selection and later filtering differ

A capture filter determines which packets are retained during collection. Packets excluded then cannot be recovered by changing a display or analysis filter later. Keep the collection question, authorized scope, interface, and expected traffic in mind before choosing a filter. An overly narrow expression can remove context needed to interpret the conversation.

Document capture duration, timestamp settings, packet-length limits, and reported drops. A truncated packet may preserve headers while omitting payload needed for later analysis. Capturing from the wrong interface can produce an apparently quiet file even when the service is active elsewhere. Tool output should be interpreted alongside the collection environment.

## A fictional DNS troubleshooting capture

A learner receives approval to examine a training host's name-resolution behavior. They collect a short, bounded sample or use a prepared capture, then compare queries and responses. The analysis records the relevant addresses, names, timing, and errors without assuming every query resulted in a later web connection.

Traffic can contain sensitive information, including material unrelated to the original question. Protect capture files and share only the appropriate scope. A command-line tool being easy to start does not establish permission to monitor a shared network. Use official documentation for the syntax supported by the installed version.

## Plan before running

Write a collection plan for a fictional local training service: the question, interface, time window, intended filter, file destination, and stop condition. State one important observation the plan might miss. Then inspect a provided sample and document the packet references that support your conclusion. This is more reproducible than pasting a terminal screenshot with no explanation of how the traffic was selected.

## Keep exploring

- [[packet-analysis]]
- [[wireshark]]
- [[network-forensics]]