On Wed, Jul 04, 2001 at 02:35:36PM +0000, ashley thomas wrote:
> Yes, I think what you said is correct. It depends on the interpretation.
> I got carried away when i saw different behaviour in Linux and BSD.
However, this brings up a problem with "pcap_stats()" - it currently has
no defined way to specify that some statistics are valid, but not all.
On pre-2.4-kernel Linux systems, "pcap_stats()" should, arguably, return
-1; the "number of packets received" statistic, as a count of packets
handed to the filter, is unavailable, as are the counts of packets
dropped due to lack of buffering space and of packets dropped by the
interface (presumably due to bad CRCs and the like).
However, on 2.4-kernel systems, libpcap can do a
SOL_PACKET/PACKET_STATISTICS "getsockopt()" call to get counts of
packets that passed the filter (not packets handed *to* the filter,
alas) and of packets dropped due to
the socket receive buffer being full;
no sockbufs being available;
which corresponds to "ps_drop".
So, on those systems, "ps_drop" can be provided, but "ps_recv" can't be.
A "pcap_stat" structure doesn't have, say, a bitmask of statistics
supplied, so a "pcap_stats()" call can't specify that "ps_drop" is
supplied but "ps_recv" isn't, for example (and it can't specify whether
"ps_ifdrop" is supplied, either, if there's ever a platform on which it
can be).
"pcap_stats()" could, I guess, set a statistic to -1, err, umm, UINT_MAX
to say "this isn't valid"; the annoyances with that are
1) if, by a stroke of bad luck, the system happens to hand to
the filter, or to drop, *exactly* 4,294,967,295 packets,
that'd look as if the statistic weren't available;
2) applications built with libpcap can't rely on that behavior,
so if they print counts as long as they're not UINT_MAX, they
might print a count of 0 even if that means "the older
libpcap with which the program is linked didn't supply the
count" rather than "no packets were {seen by the filter, dropped
due to a lack of buffer space, dropped by the interface}".
1) may not be a huge problem.
2) wouldn't make matters any worse unless applications start displaying
the value of "ps_ifdrop" - but if they display it only if it's non-zero,
it wouldn't, I think, be any worse than it is now.
Now, a count of packets that passed the filter can also be a useful
statistic; libpcap doesn't need to maintain that filter - the
application could maintain it itself - but it might be nice to have
libpcap keep a count of those as well, separate from "ps_recv".
(Arguably, tcpdump should maintain that count, and print it as well as
printing "ps_recv" - but printing "ps_recv" only if it's greater than
the count of packets tcpdump saw; if it's less, "ps_recv" is obviously
bogus, and if it's equal, it means either that there was no filter,
every packet passed the filter, or "ps_recv" was counting only packets
that passed the filter, and, in all cases, "ps_recv" isn't interesting.)
However, adding a field to "pcap_stat" breaks binary compatibility with
shared libpcap libraries, so that, if possible, libpcap shared library
builds should arrange that the new library not be used by programs
linked with the old library. (It's possible on most if not all
UNIX-flavored systems, by changing the major version number of the
shared library; I don't know if it's possible on Windows.)
Another possibility might be to introduce a new API that either fills in
a new structure, containing more fields and a bitmap of valid
statistics, or returns a count of statistics returned and either
fills in a structure with space for a full-sized list of
type/value pairs
or
fills in a pointer to a mallocated structure with a list of
type-value pairs
with the types being #defines (or "char *"s pointing to statistic names)
specifying what particular statistic the matching value is.
-
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
