A long dumpcap capture ends with a 'Packets received/dropped on interface' line showing drops; where were the packets lost, and what do you change?
answer
- four counters in brackets
- the percentage is what survived
- OS buffer versus dumpcap itself
- -B and -s
- zero is not always proof
basics
~20 sThe bracketed counters say where: pcap means the operating system's capture buffer overflowed (raise -B, cut -s, use a faster disk), dumpcap means dumpcap failed to write or queue packets, flushed means packets arriving after stop, and ps_ifdrop counts the interface or driver.
solid answer
~40 sdumpcap's closing line, `Packets received/dropped on interface 'eth1': 9000000/450000 (pcap:450000/dumpcap:0/flushed:0/ps_ifdrop:0) (95.2%)`, splits the loss. **pcap** is the kernel buffer filling before dumpcap read it: raise `-B` from its 2 MiB default, shorten the snapshot length with `-s` if you only need headers, write to a fast local disk and keep the host otherwise quiet. **dumpcap** counts packets dumpcap itself lost, typically a failed write to the output file, which also ends the capture. **flushed** is packets that arrived after the stop request. **ps_ifdrop** is the interface or driver, and zero may only mean it is not reported. The trailing percentage is the share *received*. None of these counters sees loss before the capture point.
go deeper
Recall that dumpcap reports how many packets it received and dropped at the end of a capture, and that dropped packets are missing from the file.
Explain the four counters, which part of the capture path each measures, and how -B, -s and the output disk affect the kernel-buffer count.
Show how you separate capture-side loss from network loss, why a zero counter can mislead, and how you document drops so analysts know which absences to distrust.
Set the bar for capture evidence: what drop rate invalidates a conclusion, when host capture must give way to dedicated capture hardware, and how drop counts travel with the file.
## Reading the line When a capture ends, dumpcap prints one line per interface (unless `-Q` silences it): ``` Packets received/dropped on interface 'eth1': 9000000/450000 (pcap:450000/dumpcap:0/flushed:0/ps_ifdrop:0) (95.2%) ``` - **9000000/450000** is packets received over total drops, where total drops = `pcap` + `dumpcap` + `flushed`. The `ps_ifdrop` value is shown alongside but is not part of that total. - **(95.2%)** is received ÷ (received + total drops): the share of packets that **made it into the capture**, not the share lost. Reading it backwards is a common slip. - When you capture from the GUI, the status bar shows a **Dropped** count, displayed only when not all packets were captured. ## What each counter means | Counter | Where the packet was lost | Typical cause | What to change | |---|---|---|---| | `pcap` | the operating system's capture buffer | dumpcap did not read fast enough during a burst | larger `-B`, smaller `-s`, faster disk, less competing load | | `dumpcap` | inside dumpcap | a write to the output file failed (a full disk, for instance), which also stops the capture; or memory for queuing packets ran out | free or move the output disk; check where the file really ends | | `flushed` | discarded after the stop request | packets still arriving while the capture shut down | nothing; normal at shutdown | | `ps_ifdrop` | the network interface or its driver | the NIC or driver could not keep up | interface and driver tuning outside Wireshark | ## Fixing kernel-buffer drops 1. **Raise `-B`.** The capture buffer defaults to 2 MiB. Set a larger value in MiB, globally before the first `-i` or per interface after it. The system may silently limit it, so re-check the counters rather than trusting the number you asked for. The GUI shows the same setting as the **Buffer** column in Capture Options. 2. **Shorten the snapshot length with `-s`.** The default, 262144, keeps whole packets. A latency or handshake investigation often needs only headers, and a short snaplen lets far more packets fit in the buffer and on disk. The price is that payloads, reassembly and anything above the headers are gone from that file. 3. **Write to a fast local disk**, not a network share or a nearly full volume. 4. **Run dumpcap headless.** A GUI busy updating the packet list in real time competes with the capture for CPU on the same host. 5. **Keep fewer packets** with a capture filter when only some traffic matters — a separate subject, but the cheapest fix of all. 6. **Re-run and compare** the counters. Drops that persist after a larger buffer, at a modest packet rate, suggest the output disk or the host's load rather than the buffer size. ## What the counters cannot tell you - They cover only the path **from the interface to the file on this host**. Packets lost before the capture point — an oversubscribed mirror port, a link discarding frames — never appear here, so zero drops does not mean the capture is complete. - **`ps_ifdrop` of zero is not proof.** libpcap's documentation says it might not be implemented, so zero can mean "unavailable" rather than "no drops". - **Platforms differ.** libpcap notes that these statistics do not behave the same way on all platforms, and that `ps_drop` is zero where it is not available. - When later analysis shows gaps in TCP sequence numbers, a capture with recorded `pcap` drops makes capture loss the first suspect; deciding which side lost the segment is a TCP-analysis subject. ## Keeping the evidence honest - A **single-file pcapng** capture ends with an Interface Statistics Block, commented "Counters provided by dumpcap", that records received and dropped counts. A pcap file has no place for them. - Copy the drop line into the hand-over note for every capture, and state which counters were non-zero, so whoever analyses the file knows which absences to distrust. - Mind the quiet options when dumpcap runs unattended. `-q` replaces the running packet count with a single count at the end, while `-Q` suppresses everything except true errors on standard error — including this closing line. A capture started from a service manager with `-Q` throws away the one record of how complete it was, so prefer `-q` and keep standard error in the service's log.
- The drop line shows zero everywhere, yet the capture is full of apparent gaps in TCP sequence numbers; what does that tell you?Zero drops means this host's capture path kept up, not that every packet reached the capture point. Loss upstream of the interface — an oversubscribed mirror port, a congested link — is invisible to these counters, and `ps_ifdrop` of zero may only mean the driver does not report it. Check how the traffic was delivered to the interface before concluding the network itself lost the segments.
- Why does a smaller snapshot length reduce pcap drops?The kernel buffer holds captured bytes, not a fixed number of packets. With `-s` cut to the headers you need, each packet takes a fraction of the space, so a burst fits before dumpcap drains it, and fewer bytes have to reach the disk. The cost is that payloads are gone, so reassembly and application-level analysis are impossible from that file.
saying these in an interview costs you the question
- The percentage at the end of the drop line is the share of packets dropped.
- Any drop on that line means the network lost packets.
- A ps_ifdrop of zero proves the network card dropped nothing.
- Setting -B always gives exactly the buffer size requested.
- Zero drops proves every packet on the link is in the capture.