On Sun, Jul 08, 2001 at 08:52:44PM +0000, Subba Rao wrote:
> I have Linux kernel 2.2.19 on one system
That doesn't say what version of what OS it is, it just says what
version of the Linux kernel the kernel in that OS is based on (it
doesn't even guarantee that the distributor hasn't applied their own
patches to the kernel).
What distribution is it, and what version of that distribution?
> and OpenBSD 2.8 on another. When I run
> tcpdump on both systems for a while and stop, I see "xxxxx packets dropped" on
> OpenBSD and not so on Linux.
Do you mean you don't see *any* "xxxxx packets dropped" message, or do
you mean you see the message but "xxxxx" is 0?
If the former, then whatever version of tcpdump you have on your machine
has been changed not to print that message; complain to whoever produced
that Linux distribution.
if the latter, it means that
the kernel doesn't include support for supplying a count of
packets dropped on the socket that libpcap is using;
the kernel does include that support, but libpcap doesn't use
it;
no packets were, in fact, dropped.
Given that it's a 2.2[.x] kernel, it could just be that the kernel
doesn't supply that information - unmodified 2.2[.x] kernels don't.
> I don't know which version of libpcap is being
> used on either system.
> (Please let me know if there is a way to find out).
You could run "tcpdump -h", although, unfortunately, that just gives the
version number that the particular libpcap library with which tcpdump
was linked supplies - it doesn't say "oh, this was LBL's 0.4, but we
added X and Y and Z and changed W".
Some Linux distributions have patched versions of libpcap, which include
changes to support kernel packet filtering if that's enabled in the
Linux kernel. Standard tcpdump.or glibpcap 0.6.2 also has changes to do
that.
The OpenBSD version is probably whatever version the OpenBSD folk have,
which started with the LBL version and had a bunch of changes made - as
of 2.8, it appears to have been synced with tcpdump.org's 0.5 version.
> On Linux, during the kernel compile I did select 'IP Accounting' option
What option is that? The "Configure.help" file for the 2.2.19 kernel
doesn't list any such option; it lists an "IP: firewalling" option
(CONFIG_IP_FIREWALL), the description for which says
You need to say Y to "IP firewalling" in order to be able to use IP
masquerading (masquerading means that local computers can chat with
an outside host, but that outside host is made to think that it is
talking to the firewall box -- makes the local network completely
invisible to the outside world and avoids the need to allocate
globally valid IP host addresses for the machines on the local net)
and IP packet logging and accounting (keeping track of what is using
all your network bandwidth) and IP transparent proxying (makes the
computers on the local network think they're talking to a remote
computer, while in reality the traffic is redirected by your Linux
firewall to a local proxy server).
which mentions "IP packet logging and accounting", but...
> which
> should give me accurate # of packets getting dropped.
...says nothing about counting packets getting dropped, just about
accounting for use of bandwidth.
In any case, the packets that would be dropped on the way to libpcap
would *NOT* be dropped by any IP code, because they don't pass *through*
the IP code on the way to libpcap - if they're IP packets, they get
delivered to the IP code, and, regardless of whether they're IP packets
or not, they *also* get delivered to the "packet socket" code; the
latter is what libpcap uses.
> Then again, I am being
> told that the IP accounting info is largely dependent on the libpcap.
Perhaps somebody told you that, but what we've been telling you is that
the count of dropped packets - which, as per my previous paragraph, is
*not* IP accounting information - is *maintained* by the kernel (so if
the kernel doesn't support it, you can't get it), and *fetched from the
kernel and supplied to the application* by libpcap (so if the version of
libpcap you're using doesn't support it, you don't get it from a
"pcap_stats()" call, regardless of whether the kernel supports it).
> How do I get accurate count of the packets dropped?
Run a 2.4[.x] kernel (or a 2.2[.x] kernel that has Alexey Kuznetzov's
turbopacket patches; I don't know whether any Linux distributions have
that patch in their 2.2[.x] kernels), and use a version of libpcap that
uses the SOL_PACKET/PACKET_STATISTICS "getsockopt()" call, on Linux
systems that support it, in "pcap_stats()".
tcpdump.org's libpcap currently doesn't support it. Alexey's patches to
libpcap do. His stuff is at
http://ftp.sunet.se/pub/os/Linux/ip-routing/lbl-tools/
If you want to use any of those patches, you're on your own.
> I do not want any packets to be dropped by the kernel,
Then either the network traffic has to be light enough that this doesn't
happen, or the packet filter expression you're using has to be
restrictive enough to reduce the network traffic that the program sees
is light enough (*and* the filtering has to be done in the kernel, which
means, on Linux, that you need a 2.2[.x] or 2.4[.x] kernel with socket
filtering enabled (CONFIG_FILTER); on OpenBSD, it's always done in the
kernel) (*and* your libpcap needs to support kernel packet filtering on
Linux; it does support it on OpenBSD), or your machine and application
and disk and so on have to be fast enough that they can keep up with the
rate of network traffic.
> and want all the packets to be processed by the
> filters. How do I increase the buffer to avoid packets from being dropped?
That depends on the OS.
On OpenBSD 2.8, the default buffer size, when a BPF device is opened, is
8K; however, libpcap tries to raise it to 32K. The maximum that OpenBSD
2.8 supports is 512K; you'd have to modify libpcap to raise it to 512K
rather than to 32K.
In the standard Linux 2.2.19 kernel, the default buffer size on a socket
(that being what's used on Linux for raw packet capture) is either 32767
or 65535, depending on whether the "IP: Allow large windows (not
recommended if <16 MB of memory)" (CONFIG_SKB_LARGE) kernel
configuration option was enabled. Libpcap doesn't change it.
It Might Be Nice if libpcap had an API to set the buffer size, so that
applications could control it; unfortunately, the kernel API in BSD
doesn't (at least on some platforms) let you set it after you've bound
the BPF device to a network interface, so it'd have to be specified at
open time, meaning that a new call to open a live capture would be
required (or it'd have to unbind and rebind the BPF device, but at least
at one point I looked into that and concluded that had problems).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
