[Snort-devel] [roesch at ...48...: Re: [Snort-admin] defrag problem fixed]

Martin Roesch roesch at ...48...
Mon Nov 20 01:35:31 EST 2000


Fyodor wrote:
> 
> going back through 'brushup list' :-)
> 
> From: Martin Roesch <roesch at ...48...>
> 
> > >
> > > * fix daemon mode on Linux
> 
> hmm.. I am unable to repeat this problem on following system:
> [root at ...124... ]# uname -a
> Linux box.notlsd.net 2.2.16 #1 SMP Mon Jul 3 14:20:42 ICT 2000 i686 unknown
> 
> anyone?

I haven't tried it lately, but I'll check out the latest CVS code and give it
a try on my RH6.2 box...

> > > * fix packet file readback on linux
> 
> this problem is more or less libpcap specific, no? i.g. if you link
> snort with old libpcap, but try to use tools linked with redhat shipped
> (read 'broken') libpcap, you run into trouble.

Yeah, I just wish we had a more graceful way of addressing it.  Maybe we
should start shipping (or integrate) the pcap fixup program from Ethereal?

> > > * look into potential PID file naming issues
> 
> ?? any followup?

I had a report of the PID filename having an extension that was the interface
number +1 (i.e. snort.hme0 => snort.hme1) on Solaris.  I tried to recreate the
problem on my local Solaris box to no avail.  Spurious behavior?  Has anyone
else seen this happen?

> >   * fix chroot relative path names
> 
> I think it's fixed more or less. Some plugins may have slipped through my eyes though
> but I fixed it everywhere I could see. From now (on? :)) all logfile names should
> be relevant to chroot if chroot is used. If initialisation is done
> after chroot took place, no changes in code need. if initialisation
> is done before chroot (i.g. in SetupPlugin function(s)) then following construction
> is suggested:
> 
>          snprintf(filename, BUFLEN, "%s%s",chrootdir == NULL ?
>                              "": chrootdir, realname);
> 
> or something. I suspect there would be no harm to use it after chroot is done,
> I modified the code so chrootdir is reset back to NULL after chrooting has been performed.

Ok, cool.  We should implement something like this and roll it out across all
of the output plugins.

> > We need to tweak the stream reassembler to use the session window size instead
> > of just allocating a 64k data buffer to each side of a connection, this is
> > going to turn Snort from a lightweight IDS to a heavyweight one.  (See
> > yesterday's "100MB memory leak" thread for proof...)
> 
> yep. have seen another post on this topic today. Looks like a pointer gets
> some random value (non-null though) which causes coredump. Needs further investigation.

I messed around with the stream reassembler memory management over the weekend
and probably broke it in an attempt to get it to use less memory.  Maybe Chris
can take a look at my mods and tell me what an idiot I am (and fix it!). :)  

> > I've had requests for a few more link layer protocols, CSLIP and ATM.  I think
> > these can wait until after 1.7.
> 
> CSLIP can do, but anyone has access to ATM hardware? Dragos? :)

Just our users... :)

> > The daemon mode issues still seem like they might be a problem on Linux.
> 
> Setting device into promisc. mode happens after child process has been forked, I don't think
> it's fork which drops promisc. mode. Anything else? I tried to repeat this problem on
> two linux systems I have access to, R.H. 6.1 and .6.2, neither of them showed up the problem.
> Anyone else is able to reproduce the problem?
> 
> > the beta out this week.
> 
> probably a bit of delay with it ;-P

As always... ;)

On the up side, I'm going to be home and available for almost the entire next
two weeks, so maybe we'll see some progress!

    -Marty

-- 
Martin Roesch
roesch at ...48...
http://www.snort.org



More information about the Snort-devel mailing list