Take the 2-minute tour ×

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?

Please advise what to look for if we want to filter those cases when no reply packets were received.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

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);


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

share|improve this answer
Also, if the packet handling is slow it is possible that the packets will be dropped in the NIC hardware before it is ever seen by the kernel. –  Craig Jan 18 '12 at 15:50
@Craig: The box running this script is virtualized, so I don'k know about NIC speed. –  tuareg85 Jan 18 '12 at 16:02
@sr_: good idea with the lines, too easy :) I guess than we don't have to use the -w switch, but simply redirect the output to a file and count line numbers. Will check that ASAP. –  tuareg85 Jan 18 '12 at 16:05
@tuareg85: to analyze the captured packets, -w is great. You can e.g. use Wireshark with it. –  sr_ Jan 18 '12 at 16:07
Killing the process too soon is probably not the issue, since we wait 3s after stopping the traffic, I think that should be enough. Also tcpdump has time to finish the error output too, and packets dropped by kernel was always 0. –  tuareg85 Jan 18 '12 at 16:09

Your Answer


