> Is the intent
> of ps_recv to count packets seen on the wire or packets that pass the
> filter?
It counts different things on different platforms. It's not clear that
either one of them can be implemented on all platforms (unless "packets
that pass the filter" is defined as "packets that pass the filter *and*
get read by libpcap, rather than being dropped because libpcap doesn't
read them fast enough", as that statistic doesn't require cooperation
from the kernel, libpcap can just increment a counter for each packet).
Ideally, there should be a call that can supply a number of statistics,
*plus* an indication of which ones it's supplying, so that if a given
statistic can't be supplied on some platform, it isn't supplied, and the
application knows it and doesn't report that statistic. Unfortunately,
"pcap_stats()" isn't such a call.
> I've done a few tests with pcap-current from 7/24 and the numbers (with
> tp_packet/ps_recv) are consistantly matching up. Its a fairly trivial
> addition
...as long as you account for the fact that not only are there systems
that don't define "PACKET_STATISTICS", there are also systems that
define it but that *don't* declare "struct tpacket_stats" - at least if
you use <netpacket/packet.h>, rather than <linux/if_packet.h>, to get
that stuff defined.
I'm not sure there's a good *technical* reason (rather than some
religious reason such as "GLIB HEADERS GOOD! KERNEL HEADERS BAD!") for
using <netpacket/packet.h>, given those problems, given that
"pcap-linux.c" has to include <linux/if_packet.h> anyway on
libc5+2.2-or-later-kernel systems just in order to be able to use
PF_PACKET sockets at all.
(This is the downside of having kernels and C libraries released
separately - the C library may not reflect all the capabilities of the
kernel, or, worse, may just *half*-reflect it, as appears to be the case
on a system here that has a <netpacket/packet.h> that defines
PACKET_STATISTICS but doesn't declare "struct tpacket_stats".)
> and I can produce a patch easily enough. What is the consensus on this?
Given that "ps_recv" means different things on different platforms, I
have no problem with it counting packets that passed the filter on Linux
systems with SOL_PACKET/PACKET_STATISTICS support, *as long as the code
compiles even on annoying systems with <netpacket/packet.h> files that
define PACKET_STATISTICS and don't declare "struct tpacket_stats"*.
Personally, I'd vote for just saying "screw <netpacket/packet.h>" and
using <linux/if_packet.h> - after all, "pcap-linux.c", as the name
suggests, *is* Linux-specific, so it's not as if you have to worry about
portability to non-Linux platforms using glibc.
Long term, I'd like to see "pcap_stats()" replaced by something better.
(I'd also like to see the BSDs be able to supply, in BPF, statistics
that count both total packets seen by the BPF code *and* packets that
passed the filter, given that the count of dropped packets is a count of
packets that passed the filter but that got dropped due to the BPF
buffer filling up, but that's another matter.)
-
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
