Thanks Claudio!!
On 12/29/09, Claudio Jeker <[email protected]> wrote:
> > Today I tried to download a 4MB file from nearby test linux server to
> > that FTP server of mine and had
> >
> > tcpdump -i eth0 -s 2000 -w capture.pcap host linux.test.server
> >
> > command running and then I find difference between the results of
> > tcpdump run on the linux server and the one run on OpenBSD. The linux
> > one shows 4847 packets captured, OpenBSD one shows 4505. Also OpenBSD
> > capture loaded in Wireshark (ver. 1.2.2) shows several bunches of TCP
> > ACK entitled "TCP ACKed lost segment". This is the conclusion of the
> > Wireshark TCP analysis, which says the capture file contains ACKs to a
> > TCP segments that are missing from the capture file.
>
> BPF is implemented as a ring buffer if it overflows it will drop packets.
> That's why tcpdump is printing the statistics at the end:
> 4 packets received by filter
> 0 packets dropped by kernel
> If you tcpdump with a snapsize of 2000 as shown above you will run out of
> the default bpf bufsize very quickly since the default is 32k
Is it so? snaplen is described as:
-s snaplen
Analyze at most the first snaplen bytes of data from each pack-
et rather than the default of 116. 116 bytes is adequate for
IPv6, ICMP, TCP, and UDP, but may truncate protocol information
from name server and NFS packets (see below). Packets truncat-
ed because of a limited snaplen are indicated in the output
with ``[|proto]'', where proto is the name of the protocol lev-
el at which the truncation has occurred. Taking larger snap-
shots both increases the amount of time it takes to process
packets and, effectively, decreases the amount of packet
buffering. This may cause packets to be lost. You should lim-
it snaplen to the smallest number that will capture the proto-
col information you're interested in.
So my understanding of the parameter is that it is the portion of a
packet that will be passed to the application using libpcap (in this
case - tcpdump). Is that incorrect understanding?
> and I guess
> you cranked up your tcp buffers to much bigger numbers so that bpf has no
> chance to queue the incomming packets, call userland and be done with them
> before the 32k buffer overflows. You may want to look into sysctl
> net.bpf.bufsize.
Ah, to a user like myself this sounds more like the factor limiting
BPF potential. With tcpsendspace being 256K obviously I missed this
one.
> --
> :wq Claudio
Thanks a lot!
