Re: Snort 2.9, RHEL 5 and afpacket DAQ [~Solved?]

[Ralf Spenneberg <ralf () spenneberg de>]

Hi Michael,

sorry for replying late. I was on a business trip the last two days.

The patch works fine for me. I still have to check the performance, but
so far everything looks good.

Picking up on the discussion concerning the max-buffer-size:
I noticed that buffer above 128M in total are not supported. Using more
that the supported interfaces gives an error message. I think that
requesting more than the supported memory should at least generate an
error message, too!

Of course, best would be to drop the restriction alltogether.

By the way, I still had one minor issue with the patch:
# patch < /root/afpacket-v4.diff 
patching file daq_afpacket.c
Hunk #10 FAILED at 628.
1 out of 17 hunks FAILED -- saving rejects to file daq_afpacket.c.rej

This was not critical since it just concerned a comment line. 

Thanks for your fast support,

Ralf


Am Mittwoch, den 20.10.2010, 18:06 -0400 schrieb Michael Altizer:
> On 10/20/2010 04:16 PM, Michael Altizer wrote: 
> > On 10/20/2010 03:14 PM, Michael Altizer wrote: 
> > > On 10/20/2010 02:59 PM, Rich Graves wrote: 
> > > > On Wed, Oct 20, 2010 at 1:12 PM, Jeff Kell wrote:
> > > >         
> > > >         I had rebuilt snort 2.8.6 with libpcap 1.1.1 and  had
> > > >         some worse performance than before, but then there was a
> > > >         discussion on one of the snort lists regarding sids 4676
> > > >         and 4677 in the oracle-rules being a pcre "hog".
> > > >         
> > > >         Disabling those two sids dropped my average CPU over
> > > >         half...
> > > >
> > > > Wow. Mine dropped over 2/3. 
> > > >
> > > > sid 4676 is limited to POSTs, so if you have a requirement to
> > > > detect ancient oracle attacks, keep that one and drop just 4677.
> > > >
> > > > The problem of the maximum 49MB buffer on RHEL5 64-bit remains
> > > > (does not affect Ubuntu 64-bit or RHEL5 32-bit; I'd expect it to
> > > > effect CentOS and other rebuilds as well), but since I'm no
> > > > longer regularly filling the buffer, my 2.9.0 installation is
> > > > now stable enough that I can start looking at the new rule
> > > > options, and hope the buffer issue gets addressed in 2.9.1.
> > > I've replicated the issue on a 64-bit CentOS 5.5 VM.  It's going
> > > to take some investigation from the kernel side of af_packet to
> > > figure out the issue since it appears to be limited to 64-bit
> > > CentOS/RHEL as you indicated.  Unfortunately, they really don't
> > > make building a custom kernel with their source easy, but I'm
> > > getting there...
> > >
> > > -Michael
> > The problem is that we're running into the old kmalloc limit of 128k
> > on the 2.6.18 kernel supplied with RHEL5/CentOS5.  The difference
> > between 49mb and 50mb is the difference between 16218 blocks and
> > 16549 blocks, which the kernel attempts to kmalloc a pointer array
> > for to keep track of the allocated pages.  On a 64-bit system:
> > 16218 * sizeof(char *) = 129744 (< 128k)
> > 16549 * sizeof(char *) = 132392 (> 128k)
> >
> > The Linux kernel started defaulting to supporting kmallocs of
> > significantly larger sizes (2mb) in 2.6.22.  See the AFPacket
> > section of the DAQ README if you're curious as to the math involved
> > with determining the number of blocks (pages) requested.
> >
> > There are a few avenues that can be explored:
> > 1. Change the AFPacket DAQ module to attempt to use initially use
> > multi-page blocks and scale back the block size on subsequent
> > allocation failures.
> > 2. Upgrade your kernel to something a bit more recent (2.6.22 came
> > out almost 3 and a half years ago).
> > 3. Change the af_packet.c on your RHEL kernel to use vmalloc instead
> > of kmalloc for the page vector and recompile, but that will have an
> > unknown impact on performance.
> >
> > I'll start looking into option 1 (probably the best option overall)
> > when I get some time.
> >
> > -Michael
> I've attached an updated version of my previous patch which
> incorporates item 1.  I've tested it on CentOS 5.5 (where the problem
> was reproduced and debugged) and have not had any issues.
>
> -Michael
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________ 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



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
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