[Snort-devel] old problem seems back

Kreimendahl, Chad J Chad.Kreimendahl at ...1167...
Thu Oct 17 12:42:03 EDT 2002

Is that revision 1.18?  

Was going to say...
If you look at these changes:
(1.16 to 1.17)... And then the changes on the moves from sourcefire
(1.18 to 1.19)

It looks like all the changes in 1.17 have been nuked by 1.19
(sourcefire).  All the changes in spp_portscan2.c made between 1.16 and
1.17 should be applied to the current code in cvs to fix the problem....
Or so it seems.

-----Original Message-----
From: Lawrence Reed [mailto:Lawrence.Reed at ...1489...] 
Sent: Thursday, October 17, 2002 10:41 AM
To: Kreimendahl, Chad J
Cc: snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] old problem seems back

Hash: SHA1

This sounds like a problem I had in the 1.9.0beta? releases.  The work
around was to disable spp_portscan2.  Now that I am running 2.0 I am
having the problem again.  Disabling spp_portscan2 again fixes it.  As a
better solution I am currently running 2.0 with the spp_portscan2.c file
from 1.9.0.  No problems yet.

Kreimendahl, Chad J wrote:

|I'm not sure if anyone else experienced this in the past, but for us
|it's come back again.  There is a system on which we run multiple
|instances of snort, some of which get high amounts of packets flying
|their way every so often.  If the CPU utilization is at 100% for
|extended periods of time, one or several of the snort processes will
|begin to hijack the CPU and try to steal ALL of its cycles.  Currently
|it's not based on whether or not it was the snort that started the CPU
|usage with all the packets, it's just random.  Now, I say this having
|note one other thing.  Along with this wonderful use of resources comes
|a failing of snort to log any of the alerts.
|We had this problem in the past and at some point in the stages between
|1.8.x and 1.9 it went away.  The only changes we've made is to change
|the binary to v2 beta... And add the two config file lines:
|config detection: no_stream_inserts, search-method mwm
|preprocessor HttpFlow: ports 80 3128 8080 depth 255
|Any code get left in sourcefires set unupdated from the other changes
|going on? Anything (debugging, stats output, stuff like that) we can do
|to help?
|On the good side of things:  The load on our systems was cut in half or
|third of what is commonly seen, as well as many other improvements,
|as CPU utilization.  
|Anyway, it all seems somewhat random, this occurrence... And we'd be
|more than willing to help by changing some things and testing.  Would
|curious to hear if anyone else has experienced a problem such as this.
|This sf.net email is sponsored by:ThinkGeek
|Welcome to geek heaven.
|Snort-devel mailing list
|Snort-devel at lists.sourceforge.net
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org


More information about the Snort-devel mailing list