On Wed, Jul 25, 2001 at 10:29:02PM -0400, Scott Barron wrote:
> Here is the patch I made for getting the stats from the Linux 2.4.x kernel.

Checked in, with some changes - for example:

> pcap-linux.c
>   Removed the dependancy on <netpacket/packet.h>
>   Don't bother incrementing ps_recv if pulling stats from kernel

...the version I checked in always increments "ps_recv", as the fact
that the system on which libpcap was built had header files that
included the stats stuff doesn't imply that the system on which it's
running includes it (consider a libpcap built on a 2.4[.x] system but
running on a 2.2[.x] system).

As, on systems that support have the PACKET_STATISTICS "getsockopt()"
option, we overwrite "ps_recv" with the value we got from the kernel,
the only potential problem with incrementing "ps_recv" for every packet
that passes the filter is a performance problem.  We could check for
that in "live_open_new()", and set a flag that's checked at run time,
but I'm not sure doing a test and conditional branch on every packet is
better than doing an increment on every packet.

> This was done against the CVS version of libpcap.  This compiles on 2.4.x
> and 2.2.x but I do not know about 2.0.x, I may have broken it by removing
> the glibc header but I think it should still work.

I'll try it on the 2.0[.x]-kernel system I have at work.

One potential problem with not using <netpacket/packet.h> is that if you
have a Linux distribution that comes with libpcap, that has a version of
glibc whose <netpacket/packet.h> defines PACKET_STATISTICS and "struct
tpacket_stats", and that comes with a choice of 2.2[.x] and 2.4[.x]
kernels, and the distribution binaries are built on a system with a
2.2[.x] kernel, the libpcap distributed with the system wouldn't use
PACKET_STATISTICS if you have a 2.4[.x] kernel.

That could probably be fixed by checking whether <netpacket/packet.h>
exists and, if it does, checking whether it or <linux/if_packet.h>
defines more of

        "struct sockaddr_ll";

        PACKET_HOST;

        PACKET_STATISTICS;

        "struct tpacket_stats";

and using the header that defines more of them.  (This fails if, say,
<netpacket/packet.h> defines the first two but not the last two, and
<linux/if_packet.h> defines the last two but not the first two, but that
would be so perverse that it's not clear it's worth supporting.)
-
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

Reply via email to