tcpdump: "packets captured" vs "packets received by filter"

Question

We have a script which calls

tcpdump -v src host <IP address> and port <port number> >>out.txt 2>>err.txt -w capture.cap

on multiple IP-s while the other parts of the script initiates some traffic in the background. We want check if packets are coming back to us, and examine manually only those cases when we receive packages. tcpdump's error output seemed fine for this at first, but.

The question is, as the subject suggests, what's the difference between "packets captured" and "packets received by filter"? There are captures, which did not record any packets, but output "0 packets captured, 2 packets received by filter" which sounds like a contradiction, since if no packets were captures, how were 2 of them filtered? At first, we had been looking for "0 packets received by filter" but that isn't alway written to error output, when there were no packets received. So what do these numbers show?

I need to know what to look for if we want to filter those cases when no reply packets were received.

Answer 1

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