Snort mailing list archives
Re: SNORT DROPPING PACKETS
From: Phil Wood <cpw () lanl gov>
Date: Sun, 23 Dec 2001 17:42:05 -0700
IF YOU DO NOT DO LINUX, JUST DELETE THIS MESSAGE Ok, if I might be so brazen, I'm quite familiar with the linux/pcap_stats issue. I published a patch to tcpdump.org libpcap this month to fix the problem you are refering to. Some facts. 1. ftp://ftp.ee.lbl.gov/libpcap.tar.Z Does NOT know about dropped packets. This is the extent of it's abilities: int pcap_stats(pcap_t *p, struct pcap_stat *ps) { *ps = p->md.stat; return (0); } 2. http://www.tcpdump.org/release/libpcap-0.6.2.tar.gz Does NOT know about dropped packets. This is the extent of it's abilities: int pcap_stats(pcap_t *handle, struct pcap_stat *stats) { *stats = handle->md.stat; return 0; } 3. http://www.tcpdump.org/daily/libpcap-current.tar.gz Does know about dropped packets! It did not know earlier in December prior to the fix I so boldly presented to snort-users () lists sourceforge net and tcpdump-workers () tcpdump org. My contribution was improved by Guy Harris of tcpdump.org. int pcap_stats(pcap_t *handle, struct pcap_stat *stats) { #ifdef HAVE_TPACKET_STATS struct tpacket_stats kstats; socklen_t len = sizeof (struct tpacket_stats); /* * Try to get the packet counts from the kernel. */ if (getsockopt(handle->fd, SOL_PACKET, PACKET_STATISTICS, &kstats, &len) > -1) { /* * 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. */ handle->md.stat.ps_recv = kstats.tp_packets; handle->md.stat.ps_drop = kstats.tp_drops; } else { /* * If the error was EOPNOTSUPP, fall through, so that * if you build the library on a system with * "struct tpacket_stats" and run it on a system * that doesn't, it works as it does if the library * is built on a system without "struct tpacket_stats". */ if (errno != EOPNOTSUPP) { snprintf(handle->errbuf, PCAP_ERRBUF_SIZE, "pcap_stats: %s", pcap_strerror(errno)); return -1; } } #endif /* * 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. */ *stats = handle->md.stat; return 0; } 4. http://home.lanl.gov/cpw/libpcap-0.6.tar.gz This is a pcap hacked to include the ring buffer stuff created by Alexey Kuznetsov. It will compile on both 2.2 and 2.4. However, you would need patches to the 2.2 kernel which I do not have at my finger tips. On 2.4 kernel if you install the shared libraries, you should be able to get tcpdump to use the ring buffer with a few judicious environment variables. THIS IS BETA. So, if you do use it, please report problems to cornett () arpa net. Anyone want to try and build snort with it? I'd appreciate a few of you brave sorts trying it out. Read the files in the libpcap directory, README.linux and README.ring. On Sun, Dec 23, 2001 at 12:45:23PM -0600, Crow, Owen wrote:
Sorry, the thing that I haven't gotten to work on Linux is an accurate count of dropped packets. That's not clear the way I wrote it. The SIGUSR1 thing still prints out the stats. I'm a Debian user mostly, but after upgrading the kernel and recompiling libpcap and snort (and tcpdump, too) I always got 0% packets dropped on a fully saturated 100Mbit pipe. I tried investigating, but there seems to be very little info on getting this to work accurately in 2.4 (not in any FAQs I could find, etc.) I tried the latest CVS of libpcap, but it just made snort core dump. If anyone knows how to make it work, please fess up. Answers containing "switch to Redhat/SuSE" will be ignored. Peace, Owen -----Original Message----- From: Greg Herlein [mailto:gherlein () herlein com] Sent: Sunday, December 23, 2001 11:17 AM To: Crow, Owen Cc: 'Bartholomew Simpson'; snort-users () lists sourceforge net Subject: RE: [Snort-users] SNORT DROPPING PACKETSI was surprised to find this isn't listed in the manual or the FAQ list. It's been covered repeatedly on the list. On Unix systems send SIGUSR1 to the Snort process: kill -USR1 <snort_pid> I don't know how on Win32 systems. Linux systems require patching to make this work as far as I can tell. I never found out how on a 2.4 system, soIswitched to FreeBSD.This is the kind of anti-linux FUD that sometimes really annoys me. Of course sending signals works on linux - you don't need a patch. It works fine - I just did it on a stock SuSE 2.4.4 kernel and a 2.4.14 kernel - both production machines. Nothing against FreeBSD - that's a fine OS as well. But geesh, check your facts about linux. Now Win32 - that's another story. I won't go there. Greg _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
-- Phil Wood, cpw () lanl gov _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- SNORT DROPPING PACKETS Bartholomew Simpson (Dec 22)
- <Possible follow-ups>
- RE: SNORT DROPPING PACKETS Crow, Owen (Dec 22)
- RE: SNORT DROPPING PACKETS Greg Herlein (Dec 23)
- RE: SNORT DROPPING PACKETS Crow, Owen (Dec 23)
- Re: SNORT DROPPING PACKETS Chris Green (Dec 23)
- Re: SNORT DROPPING PACKETS Phil Wood (Dec 23)
- Incident Identification Frank Reid (Dec 23)
- Re: Incident Identification Phil Wood (Dec 23)
- same SRC/DST James (Dec 24)
- Re: same SRC/DST Kyle R Maxwell (Dec 25)
- Re: same SRC/DST James (Dec 25)
- Re: same SRC/DST Ashley Thomas (Dec 25)
- Re: Incident Identification (data in TCP syn packet) Matt Kettler (Dec 26)
- Re: Incident Identification (data in TCP syn packet) james (Dec 26)
- I want to dump full packets, but just for one rule james (Dec 26)