[Snort-devel] 2GB maximum binary log file size...

Abe L. Getchell abegetchell at ...243...
Sun Nov 11 12:36:06 EST 2001


Greetings all!

I've run into a bit of a snag with a project that I'm working on.  I
have a rather large network with a high-volume of traffic.  I have a
number of sensors which are collecting packets dumps from a number of
different segments of said network.  Every hour, the packet dumps are
rotated, and sent back to a centralized server for post-processing...
Well that's the plan at least.  The problem is, Snort is apparently
unable to handle a binary packet dump file over 2GB.  The result is a
core dump and a 'File size limit exceeded' error message printed to the
console.  The OS is Red Hat Linux 7.2 tested with Snort 1.8.1-RELEASE
and the latest build as of about two days ago.  Rotating the logs more
than once and hour isn't an option.

I grabbed this e-mail off of Red Hat's ext3-users mailing list that came
through a couple of days ago which seems to hit the nail on the head as
to what the problem may be.  Theodore Tso [tytso at ...935...] writes:

"Ext3 (and ext2) does support large files, but you need to make sure
that your application programs are (at a minumum recompiled, or
preferably, rewritten) to use the LFS standard.  The fundamental problem
is that off_t on ia32/linux is a signed 32 bits quantity, which limits
you to 2GB files.  There is a magic #define you can use with recent
Linux glibc libraries which will redefine off_t to be 64 bits, but this
can break library interfaces which happen to use off_t in function
prototypes or in library data structures.  It's better to use the
new/native LFS interfaces: open64(), read64(), lseek64(), etc., and use
the new LFS loff_t data type, if you want to be sure that you don't
accidentally break something...."

Is there any good reason why the "magic #define" or the new LFS
interfaces aren't used in Snort?  This added file size limit would be
very handy for those of us using Snort which are grabbing mass amounts
of data off of high volume networks.

Thanks,
Abe

--
Abe L. Getchell
Security Engineer
abegetchell at ...243...





More information about the Snort-devel mailing list