Re: Snort 2.9, RHEL 5 and afpacket DAQ

[Michael Altizer <xiche () verizon net>]

  The reproduction was on another RHEL5 machine, I assume?  I'll look 
into reproducing it this evening.

On 10/20/2010 03:30 AM, Ralf Spenneberg wrote:
> Funny thing. I just reproduced the error on another machine with just 2
> GB RAM. The first machine had 4GB.
> In both cases the buffer may only use 49 Megs. As soon as I use
> --daq-var buffer_size_mb=50
>
> it complains using the error message below. It works fine using Fedora12
> on the same hw.
>
> Any ideas?
>
> I think this will pose some problems for people deploying RHEL/CentOS
> sensors because of the support in the VRT rulesets.
>
> Ralf
>
>
> Am Dienstag, den 19.10.2010, 10:23 +0200 schrieb Ralf Spenneberg:
> > Hi Michael,
> >
> > here you go.
> > Using
> > # snort --daq afpacket --daq-var buffer_size_mb=50 --daq-var debug
> >
> > I get:
> > ...
> > Commencing packet processing (pid=9750)
> > Decoding Ethernet
> > Version: 0
> > Header Length: 32
> > AFPacket Layout:
> >    Frame Size: 1584
> >    Frames:     33098
> >    Block Size: 4096
> >    Blocks:     16549
> > ERROR: Can't start DAQ (-1) - create_rx_ring: Couldn't create kernel RX
> > ring on packet socket: Cannot allocate memory!
> > Fatal Error, Quitting..
> >
> > on RHEL 5.
> >
> > snort --daq pcap --daq-var buffer_size=128000000
> > using libpcap-1.1.1 works (at least runs)
> > I still have to confirm somehow that the buffer is created and used.
> >
> >
> > By the way. Using 48M works too:
> > # snort --daq afpacket --daq-var buffer_size_mb=48 --daq-var debug
> > ...
> > Decoding Ethernet
> > Version: 0
> > Header Length: 32
> > AFPacket Layout:
> >    Frame Size: 1584
> >    Frames:     31774
> >    Block Size: 4096
> >    Blocks:     15887
> >
> > Any ideas?
> >
> >
> >
> > Ralf
> >
> >
> >
> >
> > Am Dienstag, den 19.10.2010, 02:46 -0400 schrieb Michael Altizer:
> > > On 10/19/2010 01:39 AM, Ralf Spenneberg wrote:
> > > > Hi Russ,
> > > >
> > > > Am Montag, den 18.10.2010, 15:36 -0400 schrieb Russ Combs:
> > > > > Check the DAQ distro README for how to use this option:
> > > > > --daq-var buffer_size_mb=<#MB>
> > > > > You pass that to Snort which gives it to afpacket.
> > > > Thanks a lot for the suggestion, but Looking at the source it should use
> > > > a default of 128M if nothing is specified.
> > > >
> > > > Anyway. I played around with the option and apparently I can set it to
> > > > 49M but not more on this system. Therefore the default did not work!
> > > > System:
> > > > RHEL5, 4GB, 64bit Kernel: 2.6.18-194.el5
> > > >
> > > > Any clue what might be the restricting factor? Oh, by the way using
> > > > PCAP-FRAMES I can use a 2GB ring buffer, so it must be some special
> > > > restriction to the afpacket ringbuffer.
> > > >
> > > > Any ideas? Anybody else using the feature on RHEL/CentOS?
> > > >
> > > > Ralf
> > > Please try using the AFPacket patch that I posted in the other thread
> > > and using the "--daq-var debug" commandline switch to spit out what
> > > layout the module is requesting from the kernel.  With your setup, it
> > > should be really hard to get -ENOMEM from the RX ring creation.  With
> > > 64-bit, there should be no limited lowmem issues, and memory
> > > fragmentation shouldn't be an issue since the page allocation order
> > > should be 1 (although it might be for the initial kmalloc of the pointer
> > > array).  The way the memory allocation is called in the kernel, this
> > > really should not fail unless you're really out of memory (__GFP_WAIT |
> > > __GFP_IO | __GFP_FS).  By the way, if you're talking about Phil Woods'
> > > PCAP library, AFPacket uses the same kernel interface to allocate and
> > > mmap the packet ring.  If all else fails, try rebooting the system to
> > > clear out memory fragmentation/leaked memory and give it another go.
> > >
> > > - Michael
> > >
> > > ------------------------------------------------------------------------------
> > > Download new Adobe(R) Flash(R) Builder(TM) 4
> > > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> > > Flex(R) Builder(TM)) enable the development of rich applications that run
> > > across multiple browsers and platforms. Download your free trials today!
> > > http://p.sf.net/sfu/adobe-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
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Download new Adobe(R) Flash(R) Builder(TM) 4
> > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> > Flex(R) Builder(TM)) enable the development of rich applications that run
> > across multiple browsers and platforms. Download your free trials today!
> > http://p.sf.net/sfu/adobe-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


------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-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