Running, either in promiscuous mode or not :

tcpdump -i "$INTERFACE" -vvv -n -XX -S -s0 -e

I got a bunch of lines and this conclusion when I stopped it :

601 packets captured
938 packets received by filter
230 packets dropped by kernel

Why the difference ? Where are the 107 packets missing ? And is it possible at all to get/capture 100% of the packets on the local network - it's just me behind a router ?

  • Are you running is as root? Is it a VM or physical machine? Which version of tcpdump and what OS? Commented Jan 9, 2016 at 18:20
  • Yes as root, on a physical fedora 22. tcpdump version is 4.7.4, libcap 1.7.3.
    – John Doe
    Commented Jan 9, 2016 at 19:33

2 Answers 2


When tcpdump "drops" packets, is because it has not enough buffer space to keep up with the packets arriving from the network.

The difference between packets captured and received can be due to implementations of the OS or tcpdump, or more commonly due to aborting the process with ^C.

Setting the buffer size per packet with "s0" has the consequence of setting it as 64KB per man tcpdump; normally at most I set it up as 1500 if using -X to see the whole packet, and if only using tcpdump to watch headers even less than that is needed - 160 bytes which is the size of IPv4 headers.

Normally working with the screen is also slower, if needing speed I would direct the output to a file if you have no need to watch it in true realtime.

From man "tcpdump":

"Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in."

  • how to make the reference yellow as I see it often in stackexchange? Commented Jan 9, 2016 at 20:47
  • for me to be sure. Last try at 160 bytes gave me 83 captured, 131 received by filter and 0 dropped by kernel : so the 48 packets are the "drops" packets you mention, aren't they ? I just see your last edit, so : yes they are. :) -- as for the yellow, I don't know.. maybe it's the link feature, not sure. Thank you !
    – John Doe
    Commented Jan 9, 2016 at 20:47
  • have you done control-C? The difference is probably packets captured that have not been processed yet. The count is also dependent on OS and tcpdump implementation apparently. Commented Jan 9, 2016 at 20:50
  • Yes I did.. I was planning to work with files anyway as I write a script, but I wanted to do some tests first. I will verify results and come back if issues. ;)
    – John Doe
    Commented Jan 9, 2016 at 20:57
  • try it with tcpdump -s 160 -c 200 where 200 is the number of packets in order not to do ^C Commented Jan 9, 2016 at 20:57

As answered elsewhere, and here, tcpdump (default since 4.0, libpcap since 1.0) has a -B NNNN option to set the buffer size (measures in NNNN*1024 bytes, defaults to 2MiB on Linux). This is a useful alternative if you don't want to set snaplen lower.


tcpdump -i "${INTERFACE}" -B 4096 -nn -w capture.pcap

You might also consider using a pcap capture filter if you are looking for packets of some known type or with known attributes and you are not interested in capturing everything.

Rui's answer includes another useful point: If you don't need to see the packet capture live, you would do better to output to a file rather than terminal.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .