Re: Question About new counter (captured) in tcpdump v3.8.1

[Guy Harris <guy () alum mit edu>]

On Jan 9, 2004, at 11:03 AM, rmkml wrote:

> I compiled/use tcpdump v3.8.1 (with libpcap 0.8.1)
>
> and I have this (repeated) example results :
>
> 11568 packets captured
> 11574 packets received by filter
> 0 packets dropped by kernel

        ...

> My question is, where diff packet passed ? (11574-11568=6)

"Packets captured" is the number of packets that tcpdump wrote to the 
capture file.

"Packets received by filter" is the number of packets that libpcap 
reports as having been "received by the filter".  The meaning of this 
is platform-dependent; in *BSD (which includes Mac OS X...), that value 
comes from a BIOCGSTATS ioctl, and counts all the packets that, *in the 
kernel*, were handed to the packet filter code.  It includes:

	packets that were dropped because BPF ran out of buffer space, but "0 
packets dropped by kernel", in *BSD, means that none were;

	packets that were rejected by the filter, but you didn't have a 
filter, so none were rejected by the filter;

	*AND* packets that were queued up in the BPF device but not yet read 
by the application (tcpdump) at the time it got the statistics.

*That's* what those 6 packets were - you interrupted tcpdump (by typing 
control-C, probably) before it had a chance to read them.  Tcpdump 
doesn't make an effort to read the last of the packets from the BPF 
device before exiting - it'd have to do more work to do that, and even 
if it did that, some other packet might show up after it did that, so 
it's not as if getting the very last packet is important anyway.

Tcpdump used not to report the "captured" counter.  The reason why I 
added the counter was because people were confused by the "received by 
filter" counter - they expected that number to be the number of packets 
in the capture file, which it rarely if ever was.

I'm not sure why tcpdump bothered to report the "received by filter" 
value at all; I suppose that if you combine it with the "dropped by 
kernel" number, you get something you might consider a measure of how 
much of the traffic is getting dropped due to lack of buffer space - 
but if you have a capture filter that discards a significant number of 
packets, it would be wrong to consider that a measure of how much 
traffic is getting dropped due to lack of buffer space, because some of 
those packets are getting dropped because the filter rejects them.  
Unfortunately, BSD's BPF doesn't supply the number of packets that 
*passed* the filter....

I think it might be a good idea to get rid of the "received by filter" 
report, given that

	1) it means different things on different operating systems (for 
example, in Linux 2.4 and later systems where the statistics are 
maintained by the kernel and filtering is done in the kernel, it's the 
number of packets that *passed* the filter);

	2) it includes, on some platforms, packets that aren't in the capture 
file, for the reasons listed above.

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe