Yes. By putting network interfaces into promiscuous mode, tcpdump is able to see exactly what is going out (and in) the network interface.
tcpdump operates at layer2 +. it can be used to look at Ethernet, FDDI, PPP & SLIP, Token Ring, and any other protocol supported by libpcap, which does all of tcpdump's heavy lifting.
Have a look at the pcap_datalink() section of the pcap man page for a complete list of the layer 2 protocols that tcpdump (via libpcap) can analyze.
A read of the tcpdump man page will give you a good understanding of how exactly, tcpdump and libpcap interface with the kernel and network interfaces to be able to read the raw data link layer frames.
I hope this sheds some light on the issue. From the manpage:
When tcpdump finishes capturing packets, it will report counts of:
packets captured (this is the number of packets that tcpdump has received and processed);
packets received by filter (the meaning of this depends on the OS on which you're running tcpdump, and possibly on the way the OS was configured - if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched by the filter expression and, even if they were matched by the filter expression, regardless of whether tcpdump has read and processed them yet, on other OSes it counts only packets that were matched by the filter expression regardless of whether tcpdump has read and processed them yet, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump);
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).
And there's a mailing list entry from 2009 explaining:
The "packets received by filter" number is the ps_recv number from a call to pcap_stats(); with BPF, that's the bs_recv number from the BIOCGSTATS ioctl. That count includes all packets that were handed to BPF; those packets might still be in a buffer that hasn't yet been read by libpcap (and thus not handed to tcpdump), or might be in a buffer that's been read by libpcap but not yet handed to tcpdump, so it can count packets that aren't reported as "captured".
Maybe the process is killed too quick? There's also a -c N flag telling tcpdump to exit when N packets were captured.
Since you're issue seems pretty specialized, you could also use libpcap directly or via one of the hundreds of language bindings.
To your question, since all you get are the captured packages in the capture.cap file, you could just look at the runs where it's not empty and examine these, i.e., uhm, count the lines?
tcpdump -r capture.cap | wc -l
There probably is a better way using libpcap to return the number of entries in the capture file...
Best Answer
As you pointed out, there is nothing in the documentation about the "packets dropped by interface" counter. So we need some source code digging.
From the source code of tcpdump, the interface drop counter is extracted from
stats.ps_ifdrop:From man pcap_stats:
And from the libpcap source code:
So the tcpdump "packets dropped by interface" counter corresponds to the packets logged as dropped in
/proc/net/devduring thetcpdumpcapture.The meaning of the
/proc/dev/netfields are explained hereTo get a better understanding of the drops, I would start by looking at the following statistics:
ethtool -S <interface>grep '' /sys/class/net/<interface>/statistics/*