Ethereal-users: Re: [Ethereal-users] filter and counter
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 24 Oct 2003 20:58:35 -0700
On Oct 24, 2003, at 5:44 AM, Dinkar Bhat wrote:
Thanks for the detailed reply. Is there is list of OSes somewhere,on which pcap_stat() does report dropped packets properly (or vice versa)?
Well, in some sense, there is. The list is in the form of comments in files with names beginning with "pcap-" in the libpcap source tree. :-)
I.e., I put in the "pcap_stats" routines comments explaining what "ps_drop" means on that platform.
In platforms that use BPF (the BSDs, including the one whose next release shows up 20:00 local time Friday 24 October 2003, and AIX, although I haven't seen its source and am thus assuming it works similarly):
* "ps_recv" counts packets handed to the filter, not packets
* that passed the filter. This includes packets later dropped
* because we ran out of buffer space.
*
* "ps_drop" counts packets dropped inside the BPF device
* because we ran out of buffer space. It doesn't count
* packets dropped by the interface driver. It counts
* only packets that passed the filter.
*
* Both statistics include packets not yet read from the kernel
* by libpcap, and thus not yet seen by the application.
In platforms that use DLPI and have "bufmod" (SunOS 5.x/Solaris
2.x/Solaris 7 and later):
* "ps_recv" counts packets handed to the filter, not packets
* that passed the filter. As filtering is done in userland,
* this does not include packets dropped because we ran out
* of buffer space.
*
* "ps_drop" counts packets dropped inside the DLPI service
* provider device device because of flow control requirements
* or resource exhaustion; it doesn't count packets dropped by
* the interface driver, or packets dropped upstream. As
* filtering is done in userland, it counts packets regardless
* of whether they would've passed the filter.
*
* These statistics don't include packets not yet read from
* the kernel by libpcap, but they may include packets not
* yet read from libpcap by the application.
In platforms that have DLPI but don't have "bufmod" (HP-UX, possibly
others):
no comment yet, but "ps_drop" is never incremented, as we have no idea whether any packets were dropped.
On Linux:* On systems where the PACKET_STATISTICS "getsockopt()" argument
* is supported on PF_PACKET sockets:
*
* "ps_recv" counts only packets that *passed* the filter,
* not packets that didn't pass the filter. This includes
* packets later dropped because we ran out of buffer
space.
*
* "ps_drop" counts packets dropped because we ran out of
* buffer space. It doesn't count packets dropped by the
* interface driver. It counts only packets that passed
* the filter.
*
* Both statistics include packets not yet read from the
* kernel by libpcap, and thus not yet seen by the
application.
*
* On systems where the PACKET_STATISTICS "getsockopt()"
argument
* is not supported on PF_PACKET sockets:
*
* "ps_recv" counts only packets that *passed* the filter,
* not packets that didn't pass the filter. It does not
* count packets dropped because we ran out of buffer
* space.
*
* "ps_drop" is not supported.
*
* "ps_recv" doesn't include packets not yet read from
* the kernel by libpcap.
Linux 2.4[.x] supports PACKET_STATISTICS, I think, although libpcap
has to have been compiled on such a system to use it. Linux 2.2[.x]
only supports it, as far as I know, if it has the Alexey Kuznetzov
turbopacket patches, although there might be some other patches to add
it. 2.0[.x] doesn't support it at all, as far as I know.
On Digital UNIX/Tru64 UNIX:
* If packet filtering is being done in the kernel:
*
* "ps_recv" counts only packets that passed the filter.
* This does not include packets dropped because we
* ran out of buffer space. (XXX - perhaps it should,
* by adding "ps_drop" to "ps_recv", for compatibility
* with some other platforms. On the other hand, on
* some platforms "ps_recv" counts only packets that
* passed the filter, and on others it counts packets
* that didn't pass the filter....)
*
* "ps_drop" counts packets that passed the kernel filter
* (if any) but were dropped because the input queue was
* full.
*
* "ps_ifdrop" counts packets dropped by the network
* inteface (regardless of whether they would have passed
* the input filter, of course).
*
* If packet filtering is not being done in the kernel:
*
* "ps_recv" counts only packets that passed the filter.
*
* "ps_drop" counts packets that were dropped because the
* input queue was full, regardless of whether they passed
* the userland filter.
*
* "ps_ifdrop" counts packets dropped by the network
* inteface (regardless of whether they would have passed
* the input filter, of course).
*
* These statistics don't include packets not yet read from
* the kernel by libpcap, but they may include packets not
* yet read from libpcap by the application.
I don't know which versions of Digital/Tru64 UNIX support filtering in
the kernel, but I think 4.x and 5.x do.
On SunOS 4.x:
* "ps_recv" counts packets handed to the filter, not packets
* that passed the filter. As filtering is done in userland,
* this does not include packets dropped because we ran out
* of buffer space.
*
* "ps_drop" presumably counts packets dropped by the socket
* because of flow control requirements or resource exhaustion;
* it doesn't count packets dropped by the interface driver.
* As filtering is done in userland, it counts packets
regardless
* of whether they would've passed the filter.
*
* These statistics don't include packets not yet read from the
* kernel by libpcap or packets not yet read from libpcap by the
* application.
(for "socket" read "bufmod" or "BSD network layer to STREAMS adapter"
or wherever that's done)
On SunOS 3.x:
* "ps_recv" counts packets handed to the filter, not packets
* that passed the filter. As filtering is done in userland,
* this does not include packets dropped because we ran out
* of buffer space.
*
* "ps_drop" counts packets dropped inside the "/dev/nit"
* device because of flow control requirements or resource
* exhaustion; it doesn't count packets dropped by the
* interface driver, or packets dropped upstream. As filtering
* is done in userland, it counts packets regardless of whether
* they would've passed the filter.
*
* These statistics don't include packets not yet read from the
* kernel by libpcap or packets not yet read from libpcap by the
* application.
On Irix:
* "ifdrops" are those dropped by the network interface
* due to resource shortages or hardware errors.
*
* "sbdrops" are those dropped due to socket buffer limits.
*
* As filter is done in userland, "sbdrops" counts packets
* regardless of whether they would've passed the filter.
*
* XXX - does this count *all* Snoop or Drain sockets,
* rather than just this socket? If not, why does it have
* both Snoop and Drain statistics?
...
* "ps_recv" counts only packets that passed the filter.
* As filtering is done in userland, this does not include
* packets dropped because we ran out of buffer space.
On Windows with WinDump:
there's no comment, and I have no idea exactly what the ps_drop
counts, but it's probably similar to BPF.
- References:
- RE: [Ethereal-users] filter and counter
- From: Dinkar Bhat
- RE: [Ethereal-users] filter and counter
- Prev by Date: Re: [Ethereal-users] writing C++ dissectors
- Next by Date: Re: [Ethereal-users] Trying... My first email.
- Previous by thread: RE: [Ethereal-users] filter and counter
- Next by thread: [Ethereal-users] plugins problem
- Index(es):
