tcpdump mailing list archives

Re: questions on -B, performance, mbufs, and


From: Guy Harris <guy () alum mit edu>
Date: Thu, 15 Sep 2011 10:40:26 -0700


On Sep 15, 2011, at 9:54 AM, Jon Schipp wrote:

I'm trying to use the -B option this time but it's not working
for me, tcpdump just prints the help menu.
tcpdump -B 2000000 -nni em0 -s0 -w test.txt
I've tried other values as well e.g. 524288, 1048576. It doesn't like any of
them.  *I'm on FreeBSD 8.2-Release and I just compiled 4.1 from the ports
though it still reports 4.0 in the help, (system came with 4.0)* What could
I be doing wrong? Feature not available in FBSD?

No, as long as you have libpcap 1.0 or later and tcpdump 4.0 or later, and tcpdump is built with it, and either

        1) tcpdump was configured using the configure script and the configure script worked correctly (i.e., found 
pcap_create() in the version of libpcap with which it was built)

or

        2) tcpdump was manually configured and the people who manually configured it did it correctly for the version 
of libpcap with it's being built

it should support the "-B" flag.

Note, however, that the argument to "-B" is not in bytes, by Kbytes (where "K" means "1024", so, pedantically speaking, 
it's short for "kibi" not "kilo").  However, a value that's too large should just silently get truncated to the limit, 
and should not cause an error to be reported.

One last question,  I had a capture that reported:
captured 92,505,041
recvfilter 92,505,061
dropped  0

There's a difference of 20 packets between the captured and recv filter
numbers. If the kernel didn't drop any, that must mean that tcpdump couldn't
hand 20 of them, right?

"N packets captured" means that tcpdump processed a total of N packets from libpcap.

"N packets received by filter" means that the BPF code in the kernel was handed N packets.

If tcpdump is stopped by, for example, a ^C, there may be packets that were handed to the BPF code in the kernel, and 
that passed the receive filter, but that were either in the kernel's buffer, not yet having been read by libpcap, or in 
libpcap's buffer, not yet having been processed by tcpdump, at the time tcpdump handled the ^C and exited.

So it meant that tcpdump didn't bother processig 20 of them, because you told it to stop processing packets by typing 
^C (or by handing it a count of packets to process).

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Current thread: