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...