A tcpdump capture on a busy Linux host ends with '48213 packets dropped by kernel'; what does that count mean, and how do you bring it down?

## The numbers at the end of a capture When tcpdump stops, it prints a summary to standard error, for example: ``` 1254330 packets captured 1302543 packets received by filter 48213 packets dropped by kernel ``` - **captured**: packets tcpdump received and processed. - **received by filter**: its meaning depends on the operating system. On Linux it counts packets that passed the filter, including those later dropped, which is why it roughly equals captured plus dropped above. - **dropped by kernel**: packets dropped **due to a lack of buffer space** by the OS capture mechanism. If the OS does not report the figure, tcpdump prints 0. - **dropped by interface**: printed only when non-zero; packets the interface or driver reported dropping before the capture saw them. ## What a kernel drop is On Linux, libpcap reads packets through a packet socket with a ring buffer shared with the kernel. The kernel copies each packet that passes the capture filter into the ring, and tcpdump drains it. When tcpdump falls behind, the ring fills and the kernel discards new packets and counts them. So: - the loss happened **at the capture point**, after the host had received the packet; - only packets that matched the filter are counted; - the count includes packets the kernel had not yet handed to tcpdump when it stopped. ## Why it matters for the analysis A capture with kernel drops has **gaps the network did not cause**. A segment missing from the file, a jump in sequence numbers, or an ACK for data that never appears may each be the capture's loss rather than the network's. Before drawing any conclusion about loss, retransmission or latency, read the summary. If drops are non-zero, capture again under better conditions or treat every gap as unproven; how an analyser labels such gaps is a separate subject. ## Bringing drops down 1. **Write, don't print.** Decoding and printing every packet to a terminal is the slowest consumer; `-w` just copies raw bytes. If you must print, use `-n`: without it, tcpdump converts host addresses and port numbers to names, and the lookups stall the read loop. 2. **Capture less.** A tighter capture filter means fewer packets are queued at all; writing that filter is its own subject. 3. **Lower the snapshot length.** The man page notes that larger snapshots effectively decrease buffering and may cause loss; a headers-only `-s` copies far less per packet. 4. **Raise the OS capture buffer** with `-B` (`--buffer-size`), in **KiB**: `-B 65536` asks for 64 MiB. Without `-B`, libpcap on Linux requests 2 MiB. A bigger buffer absorbs bursts; it cannot rescue a sustained rate tcpdump cannot drain. 5. **Write to fast local storage**, not a network filesystem or a disk the service is already saturating. | Counter | Where the packet was lost | What it says about the network | |---|---|---| | dropped by kernel | the capture buffer, after the host received it | nothing | | dropped by interface | the NIC or driver, before the capture | the host lost it, not the path | | missing but not counted | upstream: a mirror port, the path, or the sender | needs other evidence | ## A zero is not a guarantee - Where the OS does not report drops, tcpdump prints 0 anyway. - Packets the NIC discarded appear only as interface drops, and only where they are reported. - A mirror port that cannot keep up loses packets before they ever reach the host; diagnosing that belongs to how packets are delivered to the capture point. ## Watching drops during a long capture - When writing with `-w` (and not reading with `-r`), `-v` makes tcpdump report the number of packets captured to standard error once per second; the man page warns that on Solaris, FreeBSD and possibly others this update can itself cause loss. - Restarting a capture just to read the counters loses the evidence window, so use a signal instead, as described below. - Compare the drop count with the capture's duration: a few hundred drops in an hour-long, low-rate capture and tens of thousands in a minute call for different conclusions. So "0 packets dropped by kernel" means only that the capture buffer did not overflow, as far as the operating system reports. On BSDs and macOS you can see the same counts mid-capture with SIGINFO (Ctrl-T where the status character is set), and on other platforms with SIGUSR1, without stopping the capture.