[Snort-users] Snort 2.9, RHEL 5 and afpacket DAQ
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!
> 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?
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.
More information about the Snort-users