[Snort-devel] snort statistics 1.9.0 <-> 1.8.7

Phil Wood cpw at ...86...
Wed Oct 16 16:52:03 EDT 2002


If you can keep the following frickets up in the air long enough to see
the light, congratulations.

The linux pcap (assuming HAVE_TPACKET_STATS) does the following:

                /* In "linux/net/packet/af_packet.c", at least in the
                 * 2.4.9 kernel, "tp_packets" is incremented for every
                 * packet that passes the packet filter *and* is
                 * successfully queued on the socket; "tp_drops" is
                 * incremented for every packet dropped because there's
                 * not enough free space in the socket buffer.
                 *
                 * When the statistics are returned for a PACKET_STATISTICS
                 * "getsockopt()" call, "tp_drops" is added to "tp_packets",
                 * so that "tp_packets" counts all packets handed to
                 * the PF_PACKET socket, including packets dropped because
                 * there wasn't room on the socket buffer - but not
                 * including packets that didn't pass the filter.
                 *
                 * In the BSD BPF, the count of received packets is
                 * incremented for every packet handed to BPF, regardless
                 * of whether it passed the filter.
                 *
                 * We can't make "pcap_stats()" work the same on both
                 * platforms, but the best approximation is to return
                 * "tp_packets" as the count of packets and "tp_drops"
                 * as the count of drops.
		*/

BSD (pcap-bpfc) pcap_stats:

        /*
         * "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.
         */

On Wed, Oct 16, 2002 at 07:10:47PM -0400, Chris Green wrote:
> Jens Krabbenhoeft <tschenz-snort-devel at ...1606...> writes:
> 
> > Hi all,
> >
> >   I realized that the snort statistics (via USR1 in -D mode, or after
> > CTRL-C in non-daemon mode) are calculated differently in snort 1.9 and
> > 1.8.7.
> >
> > The code-snippets show:
> >
> > 1.9.0:
> >     LogMessage("Snort analyzed %d out of %d packets, ", 
> >             ps.ps_recv, ps.ps_recv+ps.ps_drop);
> >  
> > 1.8.7:
> >     LogMessage("Snort analyzed %ld out of %d packets, ", 
> >             (unsigned long) recv, ps.ps_recv);
> >
> > So the total number of packets is in 1.9.0 the number of "ps_recv" plus
> > "ps_drop", in 1.8.7 just ps_recv.
> >
> 
> I need to go investigate why ps drop came in.  I think it's because of
> Phil wood :)  Perhaps it's my fault for not removing the addition in
> the recv...
> 
> Flagged to my todo list :)
> 
> > After having a look into libpcap (0.7.1 linux), I found the following:
> >
> >     * When the statistics are returned for a PACKET_STATISTICS
> >     * "getsockopt()" call, "tp_drops" is added to "tp_packets",
> >     * so that "tp_packets" counts all packets handed to
> >     * the PF_PACKET socket, including packets dropped because
> >     * there wasn't room on the socket buffer - but not
> >     * including packets that didn't pass the filter.
> >
> > Thus snort 1.8.7 reports the correct number of received packets (when i
> > tcpreplay a pcap file with 997083 packets, snort reports 997083 received
> > packets), whereas 1.9.0 reports more packets than 997083 as received
> > ones, because it adds the number of dropped packets onto them once
> > again. So after having replayed the mentioned pcap-file I got following
> > output:
> >
> > Snort analyzed 997083 out of 1602036 packets, dropping 604953(37.762%) packets
> > (the summary-statistics for the protocols summed up roughly give the
> > difference between 997083 and 604953).
> >
> > Is this a known bug - or not a bug but a feature, or better to say, the
> > way snort(-developers) see the sense of ps_recv/ps_drop (I know, that
> > pcap-implementations on different platforms handle ps_recv/ps_drop
> > differently :|)?
> >
> > Regards,
> >
> > 	Jens
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/snort-devel
> 
> -- 
> Chris Green <cmg at ...402...>
> Eschew obfuscation.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

-- 
Phil Wood, cpw at ...86...





More information about the Snort-devel mailing list