[Snort-devel] snort statistics 1.9.0 <-> 1.8.7
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.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
Phil Wood, cpw at ...86...
More information about the Snort-devel