tcpdump with Ctrl+C and got this total summary:
579204 packets captured 579346 packets received by filter 142 packets dropped by kernel
What are the "packets dropped by kernel"? Why does that happen?
From the tcpdump's manual:
packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).
A bit of explanation:
tcpdump captures raw packets passing through a network interface.
The packets have to be parsed and filtered according to rules specified by you in the command line, and that takes some time, so incoming packets have to be buffered (queued) for processing.
Sometimes there are too many packets, they are saved to a buffer, but they are saved faster than processed, so eventually the buffer runs out of space, so the kernel drops all further packets until there is some free space in the buffer.
You can increase the buffer size with the
--buffer-size) option like this:
tcpdump -B 4096 ....
Note that the size is specified in kilobytes, so the line above sets the buffer size to 4MB.
packets dropped by kernel (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).
The kernel puts captured packets in a fixed-size capture buffer. If
tcpdump doesn't empty that buffer quickly enough, the kernel will begin overwriting old packets in the buffer and correspondingly incrementing the dropped counter. The value of that counter is what you see as "dropped by kernel".
By the way, you can resize the capture buffer: Pass
-B option with a KiB size.
Besides what the man page says, there appears to be some additional reason why packets may be dropped by the kernel. I was experiencing 100% packet drop from
tcpdump where the only traffic on the network was one 512B packet of PRBS per second. Clearly the buffer space explanation doesn't make sense here - I think the kernel can handle 0.5kiB/s.
Something that came along with my distro (Ubuntu 14.04) may have been doing some sort of smart filtering at the link layer that didn't like my test packets. My workaround was to create a new network namespace as follows:
sudo -i ip netns add debug ip link set dev eth0 netns debug ip netns exec debug bash ifconfig eth0 220.127.116.11 up
In the inner
netns shell, whatever OS processes that were causing problems before are out of the picture and
tcpdump shows me all of the packets I expect to see.