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

[Jon Schipp <jonschipp () gmail com>]

Hello Guy,

I'm now doing testing with tcpdump on an Ubuntu machine.

One difference I noticed was that in addition to "dropped by kernel",
tcpdump on Ubuntu also reports
"dropped by interface".

Is this specific to Linux, because I haven't experienced this on FreeBSD? Is
this Ubuntu distro addendum or has this been added by the tcpdump team.

Where do the numbers come from for the "dropped by interface", you've
already explained the "dropped by kernel"
I was just wondering how this differs. Would this be the number reported by
ifconfig?

Sorry for all the questions. I will be giving a presentation at a security
conference next month and I just want to make sure I get everything as
correct as I can. Most of the questions are just for verification.

Thanks

On Thu, Sep 15, 2011 at 1:40 PM, Guy Harris <guy () alum mit edu> wrote:

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



-- 
- Jon
-- 
------------------------------------------------------------------

VMB: 812-682-0231

Dubois County Linux User Group - http://www.dclinux.org
Southern Indiana Computer Klub - http://sickbits.networklabs.org
Bloomington FOOLS - http://www.bloomingtonfools.org/
BloomingLabs -  http://www.bloominglabs.org
ISSA-Kentuckiana  -  http://issa-kentuckiana.org

GPG Key ID: 810903CB
Key fingerprint = 0069 ED69 EABB DF84 5983  AD3C 6C20 BEFD 8109 03CB
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.