[Snort-users] Snort 2.9, RHEL 5 and afpacket DAQ

Michael Altizer xiche at ...3147...
Tue Oct 19 02:46:29 EDT 2010

  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

More information about the Snort-users mailing list