[Snort-users] improving performance of the defrag module

Martin Roesch roesch at ...421...
Fri Jan 26 14:41:58 EST 2001

Reducing the timeout value isn't a good idea because the default timeout
on most operating systems ranges from 30-90 seconds.  If someone is
xmitting frag packets slowly, you're going to miss them (which can be
part of an attack).  The timeout value should really be extended

I'd question why you're seeing so much fragmented traffic on your
segment, it really seems like this shouldn't be happening.  If you
aren't actually seeing that much fragmentation then something else might
be going on, maybe there's some loop that the system is getting stuck

Can you give us more information (OS, number of frags/second on the net,


Bill Marquette wrote:
> > When I use the defrag module, it maxes out the CPU on a PIII 733 when I'm
> > sniffing a 25Mb/sec link.  I was looking at the source, and I found this:
> >
> > #define FRAGTIMEOUTSEC      10      /* 10 seconds let's play safe for now */
> > #define FRAGTIMEOUTUSEC      0      /* 0 micro seconds                  */
> > #define FASTSWEEPLIM      16000000      /* memory use threhold for fast
> > sweep */
> >
> >
> > If I reduce the FRAGTIMEOUTSEC from 10 down to something like 2, won't the
> > keep the size of the splay tree smaller and reduce search times?  Will
> > either of the other 2 settings do anything useful for me?
> >From what I understand of the defrag code (and splay tree's), yes it will most
> likely keep your tree smaller _if_ you have alot of fragments to keep track of.
> It won't necessarily result in reduced search times as splay tree's try and keep
> the most recently accessed node at the top of the tree and if you fail to get
> numerous fragments you won't have sped up the search at all.  The downside to
> changing the timeout to a smaller value is that you incure the added CPU usage
> of cleaning up the tree more frequently.  I might have interpretted the code
> wrong, but last I looked at it that was my impression.  You also reduce the
> chance that a (intentionally?) delayed" fragment won't get reassembled within
> snort and won't get alerted on.
> --Bill
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users

Martin Roesch
roesch at ...421...

More information about the Snort-users mailing list