[Guy Harris <guy@xxxxxxxxxxxx>]

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.