Articles

tcpdump Interview Exercises: Capture Filters, Missing Packets, and Connection Evidence

Practice tcpdump interview exercises on capture filters, namespaces, snap length, rotation, missing packets, and the limits of TCP connection evidence.

An empty tcpdump trace is not proof that a client never sent a request. You may be watching the wrong network namespace, selecting only one direction, filtering out the reply, or discarding bytes that would explain the failure. A technically correct command can still answer the wrong question.

The central skill in tcpdump interview exercises is to define a capture contract: where you observe, what matches, how much you save, how long you collect, and which conclusions the evidence supports. Start with that contract before interpreting a single TCP flag.

Evidence boundary: the tcpdump and libpcap manuals establish command and filter semantics; Linux documentation establishes namespace and offload behavior. The examples are original. Their filter results were checked against a synthetic saved capture using macOS tcpdump, not by collecting production traffic or running a Linux container experiment. For broader investigation practice, use Diagnose Slow Network Throughput Including Containers.

Exercise 1: write the capture contract before the command

An interviewer gives you this original scenario: a Linux service in network namespace appns connects through its eth0 interface to 203.0.113.20 on TCP port 443 or 8443. You need both directions, enough saved bytes for later analysis, and bounded file rotation. The addresses are documentation examples; the interface and namespace are assumptions of the exercise.

A proposed command is:

sudo ip netns exec appns tcpdump \
  -i eth0 -nn -s 0 -C 10 -W 3 \
  -w /tmp/service.pcap \
  'tcp and host 203.0.113.20 and (port 443 or port 8443)'

Read it in layers. Namespace selection establishes the network context; interface selection establishes the observation point; the expression defines eligible traffic. The remaining options control naming, saved bytes and rotation. The command is a Linux teaching example, not an instruction to inspect an unfamiliar host without permission.

Official Linux documentation explains that network namespaces isolate interfaces, routing tables, firewall rules and sockets. ip netns exec runs a command in a named namespace. Host eth0 and namespace eth0 are not interchangeable merely because their names match. First establish where the service actually runs and how its traffic leaves that context. Network namespaces, ip-netns

A complete answer also states a stop condition. The size-based ring rotates files; it does not set a duration. Stop after the agreed reproduction window or use a separately approved process timeout. -c limits matching packets, which may never arrive; it is not a wall-clock deadline. Preserve the final capture statistics and command alongside the files so another engineer knows what was observed.

Exercise 2: repair the filter without losing replies

Here is the faulty expression:

tcp and host 203.0.113.20 and port 443 or port 8443

The libpcap filter language gives and and or equal precedence and associates them left to right. The final or port 8443 can admit unrelated traffic, including UDP packets on that port. This differs from the precedence people often remember from programming languages. Parentheses are a correctness requirement for the intended grouping. Official pcap-filter source

The corrected expression is:

tcp and host 203.0.113.20 and (port 443 or port 8443)

Single quotes keep the shell from treating parentheses as shell syntax. host and port without a direction qualifier match either endpoint; that is useful for request and reply traffic. Replacing host with dst host would omit a server response whose source is 203.0.113.20.

Our original six-packet fixture makes the difference measurable:

Synthetic packet	Correct expression	Faulty expression
Client → target:443, TCP SYN	Included	Included
Target:443 → client, TCP SYN-ACK	Included	Included
Client → target:443, TCP ACK	Included	Included
Unrelated host → unrelated host:8443, TCP SYN	Excluded	Included
Unrelated host → unrelated host:8443, UDP	Excluded	Included
Client → target:8443, TCP SYN	Included	Included

The correct expression matches four packets; the faulty one matches six. Adding dst host to the correctly grouped expression matches three and loses the SYN-ACK. These are results from an offline synthetic Ethernet/IPv4 capture, not measurements of network reliability.

Before collecting a large trace, test the expression on a representative saved file. tcpdump -r fixture.pcap -d 'expression' compiles the filter for that file's link type without capturing live traffic. The libpcap compilation API similarly takes the link-layer context from its capture handle. A syntactically valid expression is only the first check; verify which positive and negative cases it actually admits. pcap_compile

Exercise 3: choose an interface and direction deliberately

On a Linux host, -i any can be useful for discovery across interfaces visible in that namespace. It does not reach every container namespace, and its cooked link-layer representation differs from a conventional Ethernet capture. Do not write an Ethernet-offset filter and assume it works identically on every capture type. Read the saved file's link-layer type. pcap-linktype

A forwarded packet may be observed at multiple interfaces, and a translated flow may have different addresses before and after NAT. Multiple appearances do not automatically mean multiple transmissions on the same link. Choose one point for counting or retain enough interface information to distinguish observations.

Direction qualifiers also depend on the environment. -Q in, out, or inout is available on supported capture platforms; it is not a portable guarantee. A request-only outbound capture cannot establish whether a response arrived. For a handshake investigation, capture both directions at a stated point, then narrow only when the task specifically requires it.

A useful interview answer names the next observation rather than saying “try any.” For example: “I would first confirm the service namespace and route, inspect its egress interface, and compare a short capture there with one at the host-side boundary.” That is a diagnostic inference from the topology, not a claim that tcpdump can reveal every stage of the path.

Exercise 4: save enough evidence and control collection cost

Snap length limits bytes retained from each packet. If the limit truncates a header or payload you later need, changing the display options cannot recover it. The libpcap API distinguishes this per-packet limit from the overall capture file size. pcap_set_snaplen

In the command above, -s 0 selects tcpdump's default large snapshot length; avoid describing it as unlimited. For ordinary packets it is intended to preserve substantially more than a small header-only snapshot, but unusually large packets and environment limits still deserve attention. Saving payload also changes the data sensitivity and collection cost. Choose the minimum evidence your authorized investigation needs.

-w writes packet records for later reading, rather than ordinary decoded terminal output. -nn suppresses hostname and service-name resolution when decoding, making endpoint addresses and port numbers easier to compare. On a busy host, printing every packet can become unnecessary collection overhead; save the bounded trace and decode it afterward.

The -C 10 -W 3 combination creates a size-rotated ring of three files using a ten-million-byte threshold per file. This is an approximate bound: file headers and the packet that crosses a threshold matter. It is not a strict guarantee of exactly 30 MB. Files can be overwritten as the ring wraps, so copy or stop the capture when the relevant interval is present. Do not combine size and time rotation options without checking their interactions in the installed manual. Official tcpdump manual source

Record the installed tcpdump/libpcap version, the namespace, the command, start and stop times, and any rotation filenames. A trace without these details can become ambiguous evidence during a later review.

Exercise 5: diagnose a packet missing from the trace

Separate at least four hypotheses: the packet did not reach the observation point; you watched the wrong point; the filter excluded it; or the collection path failed to retain it. A missing record alone cannot choose among them.

Official libpcap documentation warns that capture statistics have platform-dependent meanings. A kernel capture-drop count refers to loss in the capture mechanism, not a direct count of network packets dropped by a router or firewall. A zero counter is not proof of a lossless capture when the platform cannot provide the relevant statistic. pcap_stats

For an original diagnostic ledger, write three columns on paper: observed fact, competing explanations, and the next discriminating check. “No SYN-ACK in this client-side file” belongs in the first column. “Server silent” and “reply excluded by directional filter” belong in the second. Replaying the filter against a broader authorized trace belongs in the third. That structure keeps a plausible story from becoming an unsupported conclusion.

Host offloads add another boundary. Segmentation offloads can make packets observed in the host stack differ from the segments sent on the wire. Large packet records or apparent checksum problems at a host observation point can reflect offload processing. Verify where the capture occurs and, if necessary, compare with an independent wire-side observation; do not declare corruption solely from the local display. Linux segmentation offloads, checksum offloads

Exercise 6: say what a handshake proves

A SYN, SYN-ACK and ACK observed for the same flow are evidence consistent with TCP connection establishment at that point. They do not prove that TLS completed, the request reached the intended application, authentication succeeded, or a response met its latency requirement.

Conversely, a visible SYN without a visible response supports a narrower statement: this capture contains a connection attempt and no matching reply during its observed interval. Check timing, both directions, filter scope, NAT and collection health before naming a cause. An ACK flag by itself does not identify a successful handshake; sequence context matters. TCP specification, RFC9293

This article deliberately stops at the observation boundary. For sequence-number reasoning and repeated transmissions, continue with the existing TCP troubleshooting interview guide. Keeping collection quality separate from transport diagnosis makes both answers easier to defend.

Sources and Further Reading

Research checked October 4, 2026. Options and capture statistics vary by platform and installed version. Examples use synthetic documentation addresses.