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:
- questions on -B, performance, mbufs, and libpcap buffers Jon Schipp (Sep 13)
- Re: questions on -B, performance, mbufs, and libpcap buffers Guy Harris (Sep 13)
- Re: questions on -B, performance, mbufs, and Jon Schipp (Sep 15)
- Re: questions on -B, performance, mbufs, and Guy Harris (Sep 15)
- Re: questions on -B, performance, mbufs, and Jon Schipp (Sep 27)
- Re: questions on -B, performance, mbufs, and Rick Jones (Sep 28)
- Re: questions on -B, performance, mbufs, and Sanjay Sundaresan (Sep 28)
- Re: questions on -B, performance, mbufs, and Rick Jones (Sep 28)
- Re: questions on -B, performance, mbufs, and Jon Schipp (Sep 15)
- Re: questions on -B, performance, mbufs, and Guy Harris (Sep 28)
- Re: questions on -B, performance, mbufs, and libpcap buffers Guy Harris (Sep 13)