From sylvain at detilly.net  Fri Aug  1 03:14:30 2003
From: sylvain at detilly.net (Sylvain de Tilly)
Date: Fri, 01 Aug 2003 12:14:30 +0200
Subject: A patch for Bro in OpenBSD
In-Reply-To: <200307131959.h6DJxvw9078004@jaguar.icir.org> (Vern Paxson's
 message of "Sun, 13 Jul 2003 12:59:57 -0700")
References: <200307131959.h6DJxvw9078004@jaguar.icir.org>
Message-ID: <87znitr8ft.fsf@mag-laptop.cfssi.net>


Hello, 

No, I've try today with the new Bro version and I have still have
problems.

=> Same warning and libbind port doesn't work well.

I didn't change my OpenBSD version from last time (I can't do it
now...).

I'll try to make new patch but not before September.

(sorry for the long time without response.)

bye,

Vern Paxson <vern at icir.org> a dit:

>> I've got warning during execution too :
>> 
>> | ./bro: ./bro : WARNING: symbol(__p_class_syms) size mismatch relink your program
>> | ./bro: ./bro : WARNING: symbol(__p_type_syms) size mismatch relink your program
>
> Let me know if you still have this problem with the new 0.8a34 release.
>
> Did you get the BIND dependencies worked out for OpenBSD?
>
> 		Vern
>

-- 
Sylvain de Tilly

"Mettons nous tout GNU !"
                un GNUdiste.


From anton at netForensics.com  Fri Aug 22 06:26:29 2003
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 22 Aug 2003 09:26:29 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <20030724083111.GA3240@net.informatik.tu-muenchen.de>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
Message-ID: <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com>

Vern and all,

I reported bro dieing here before, but now (with 0.34) it happens EVERY
DAY. I suspect the ongoing ICMP "rain" is to blame as well, since I don't
think it was happening that often before that. As usual, there are no
messages in the logs and no core file (ulimit is set).

I would appreciate any hints for finding out what happens. I can send my
policy file over, if needed.

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH
Senior Security Analyst
netForensics -  http://www.netForensics.com
732-393-6071


From scampbell at lbl.gov  Fri Aug 22 08:05:15 2003
From: scampbell at lbl.gov (scott campbell)
Date: Fri, 22 Aug 2003 08:05:15 -0700
Subject: bro dies (every day)
In-Reply-To: <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de> <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk> <20030724083111.GA3240@net.informatik.tu-muenchen.de> <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com>
Message-ID: <3F46312B.1000604@lbl.gov>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anton Chuvakin, Ph.D. wrote:
| Vern and all,
|
| I reported bro dieing here before, but now (with 0.34) it happens EVERY
| DAY. I suspect the ongoing ICMP "rain" is to blame as well, since I don't
| think it was happening that often before that. As usual, there are no
| messages in the logs and no core file (ulimit is set).
|
| I would appreciate any hints for finding out what happens. I can send my
| policy file over, if needed.
|
| Best,
I experienced the same problem and tracked down a possible source of the
problem.

I took a quick look at the icmp code, and did a little testing.  During
this I noticed the following:  when *any* tracefile with icmp in it is
run through bro, there will be an exception at close time (ie after
net_done() is called).

On a trace file of ~500 icmp packets (and only icmp), the following data
was provided from the exec trace file:

0.000000 <no location>:0        event called: bro_init()

1060118249.065749 <no location>:0       event called: net_done(t =
'1060118249.06575')

1060118249.065749 <no location>:0       event called:
connection_state_remove(c = '[orig_h=128.55.128.84, resp_h=128.3.11.35,
itype=8, icode=0]')

In the info (ie stderr) file the following can be found:

1060118249.065749 <no location> (128.3.11.35): bad tag in Val::CONVERTER

which seems to correlate with the last event logged.  Regular logged
data seems to indicate that only the last icmp packet seems to tickle
this bug.

When a single pair of icmp ping request-response are run through, the
same problem presents itself, with the 'connection_state_remove' call
getting the orig_h and resp_h IPs *backwards* with respect to the icmp
flow object defined when icmp.bro is loaded.

Loading the icmp.bro module seems not to effect this problem, although I
am seeing strange behavior with regard to some packet payload analysis
that is going on (modified icmp.bro).

If anyone has a good idea as to the location of the problem, I would be
most happy in working with them in resolving this issue.  Recently a
modified sk rootkit with an icmp backdoor was discovered at another lab,
so keeping an eye on this protocol has just been rased in priority.

thanks!

scott campbell

- -----
Scott Campbell
NERSC Network Security
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/RjErK2Plq8B7ZBwRAk/JAKChL6AYcImWlqZHWdu0knkcfiJ7kACg2BdD
Qu3KPC55tMcP5VWC7j9hbLg=
=EfOJ
-----END PGP SIGNATURE-----



From sommer at in.tum.de  Fri Aug 22 09:03:39 2003
From: sommer at in.tum.de (Robin Sommer)
Date: Fri, 22 Aug 2003 18:03:39 +0200
Subject: bro dies (every day)
In-Reply-To: <3F46312B.1000604@lbl.gov>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de> <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk> <20030724083111.GA3240@net.informatik.tu-muenchen.de> <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
Message-ID: <20030822160339.GA25322@net.informatik.tu-muenchen.de>


On Fri, Aug 22, 2003 at 08:05 -0700, Scott Campbell wrote:

> 1060118249.065749 <no location> (128.3.11.35): bad tag in Val::CONVERTER

Could you try the attached patch and see if it helps?

Robin

-- 
Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Munich    * Phone (089) 289-18006 *  sommer at in.tum.de 
-------------- next part --------------
diff -uNrbB bro-pub-0.8a34/ICMP.cc bro-patched/ICMP.cc
--- bro-pub-0.8a34/ICMP.cc	Sun Jul 13 21:23:45 2003
+++ bro-patched/ICMP.cc	Mon Aug 18 13:02:53 2003
@@ -30,6 +30,7 @@
 		const ConnID* id, const struct icmp* /* icmpp */)
 : Connection(s, k, t, id)
 	{
+	icmp_conn_val = 0;
 	}
 
 void ICMP_Connection::Done()
@@ -98,19 +99,19 @@
 
 RecordVal* ICMP_Connection::BuildICMPVal()
 	{
-	if ( ! conn_val )
+	if ( ! icmp_conn_val )
 		{
-		conn_val = new RecordVal(icmp_conn);
+		icmp_conn_val = new RecordVal(icmp_conn);
 
-		conn_val->Assign(0, new AddrVal(orig_addr));
-		conn_val->Assign(1, new AddrVal(resp_addr));
-		conn_val->Assign(2, new Val(type, TYPE_COUNT));
-		conn_val->Assign(3, new Val(code, TYPE_COUNT));
+		icmp_conn_val->Assign(0, new AddrVal(orig_addr));
+		icmp_conn_val->Assign(1, new AddrVal(resp_addr));
+		icmp_conn_val->Assign(2, new Val(type, TYPE_COUNT));
+		icmp_conn_val->Assign(3, new Val(code, TYPE_COUNT));
 		}
 
-	Ref(conn_val);
+	Ref(icmp_conn_val);
 
-	return conn_val;
+	return icmp_conn_val;
 	}
 
 int ICMP_Connection::IsReuse(double /* t */, const u_char* /* pkt */)
diff -uNrbB bro-pub-0.8a34/ICMP.h bro-patched/ICMP.h
--- bro-pub-0.8a34/ICMP.h	Sat Oct 26 19:03:53 2002
+++ bro-patched/ICMP.h	Mon Aug 18 13:02:53 2003
@@ -54,6 +54,7 @@
 	virtual void NextICMP(double t, const struct icmp* icmpp,
 				int len, int caplen, const u_char*& data);
 
+	RecordVal *icmp_conn_val;
 	int type;
 	int code;
 };
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20030822/71cb2912/attachment.bin 

From anton at netForensics.com  Fri Aug 22 09:06:09 2003
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 22 Aug 2003 12:06:09 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <20030822160339.GA25322@net.informatik.tu-muenchen.de>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
Message-ID: <Pine.LNX.4.56.0308221205310.22141@anton.netforensics.com>

>Could you try the attached patch and see if it helps?
Hmm, what does it actually do?

-- 
Anton Chuvakin, Ph.D., GCIA, GCIH
Senior Security Analyst
netForensics -  http://www.netForensics.com
732-393-6071


From rpang at CS.Princeton.EDU  Fri Aug 22 10:56:44 2003
From: rpang at CS.Princeton.EDU (Ruoming Pang)
Date: Fri, 22 Aug 2003 13:56:44 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <Pine.LNX.4.56.0308221205310.22141@anton.netforensics.com>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308221205310.22141@anton.netforensics.com>
Message-ID: <Pine.LNX.4.55.0308221354130.25949@willy.CS.Princeton.EDU>

> >Could you try the attached patch and see if it helps?
> Hmm, what does it actually do?

The original code uses the same variable 'conn_val' for two different
purposes. This patch fixes this problem by using a separate variable.

Ruoming




From rpang at CS.Princeton.EDU  Fri Aug 22 11:10:36 2003
From: rpang at CS.Princeton.EDU (Ruoming Pang)
Date: Fri, 22 Aug 2003 14:10:36 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <20030822160339.GA25322@net.informatik.tu-muenchen.de>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
Message-ID: <Pine.LNX.4.55.0308221408450.25949@willy.CS.Princeton.EDU>

Below is a newer version of Robin's patch.

Ruoming

diff -c bro-pub-0.8a34/ICMP.cc bro/ICMP.cc
*** bro-pub-0.8a34/ICMP.cc      Sun Jul 13 12:23:45 2003
--- bro/ICMP.cc Fri Aug 22 11:04:22 2003
***************
*** 30,35 ****
--- 30,36 ----
                const ConnID* id, const struct icmp* /* icmpp */)
  : Connection(s, k, t, id)
        {
+       icmp_conn_val = 0;
        }

  void ICMP_Connection::Done()
***************
*** 82,91 ****
                                int /* len */, int /* caplen */,
                                const u_char*& /* data */)
        {
!       Event(icmp_sent);
        }

! void ICMP_Connection::Event(Func* f)
        {
        if ( ! f )
                return;
--- 83,92 ----
                                int /* len */, int /* caplen */,
                                const u_char*& /* data */)
        {
!       ICMPEvent(icmp_sent);
        }

! void ICMP_Connection::ICMPEvent(Func* f)
        {
        if ( ! f )
                return;
***************
*** 98,116 ****

  RecordVal* ICMP_Connection::BuildICMPVal()
        {
!       if ( ! conn_val )
                {
!               conn_val = new RecordVal(icmp_conn);

!               conn_val->Assign(0, new AddrVal(orig_addr));
!               conn_val->Assign(1, new AddrVal(resp_addr));
!               conn_val->Assign(2, new Val(type, TYPE_COUNT));
!               conn_val->Assign(3, new Val(code, TYPE_COUNT));
                }

!       Ref(conn_val);

!       return conn_val;
        }

  int ICMP_Connection::IsReuse(double /* t */, const u_char* /* pkt */)
--- 99,117 ----

  RecordVal* ICMP_Connection::BuildICMPVal()
        {
!       if ( ! icmp_conn_val )
                {
!               icmp_conn_val = new RecordVal(icmp_conn);

!               icmp_conn_val->Assign(0, new AddrVal(orig_addr));
!               icmp_conn_val->Assign(1, new AddrVal(resp_addr));
!               icmp_conn_val->Assign(2, new Val(type, TYPE_COUNT));
!               icmp_conn_val->Assign(3, new Val(code, TYPE_COUNT));
                }

!       Ref(icmp_conn_val);

!       return icmp_conn_val;
        }

  int ICMP_Connection::IsReuse(double /* t */, const u_char* /* pkt */)
diff -c bro-pub-0.8a34/ICMP.h bro/ICMP.h
*** bro-pub-0.8a34/ICMP.h       Sat Oct 26 10:03:53 2002
--- bro/ICMP.h  Fri Aug 22 10:46:46 2003
***************
*** 43,49 ****

        ConnectionType ConnType() const { return CONN_ICMP; }

!       void Event(Func* f);

        void Describe(ODesc* d) const;

--- 43,49 ----

        ConnectionType ConnType() const { return CONN_ICMP; }

!       void ICMPEvent(Func* f);

        void Describe(ODesc* d) const;

***************
*** 54,59 ****
--- 54,60 ----
        virtual void NextICMP(double t, const struct icmp* icmpp,
                                int len, int caplen, const u_char*& data);

+       RecordVal *icmp_conn_val;
        int type;
        int code;
  };




From anton at netForensics.com  Fri Aug 22 13:36:58 2003
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 22 Aug 2003 16:36:58 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <Pine.LNX.4.55.0308221408450.25949@willy.CS.Princeton.EDU>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.55.0308221408450.25949@willy.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.56.0308221636210.24564@anton.netforensics.com>

>Below is a newer version of Robin's patch.

[anton at bastion anton]$ patch -p0 < bro.patch
patching file bro-pub-0.8a34/ICMP.cc
Hunk #1 FAILED at 30.
Hunk #2 FAILED at 83.
Hunk #3 FAILED at 99.
3 out of 3 hunks FAILED -- saving rejects to file
bro-pub-0.8a34/ICMP.cc.rej
patching file bro-pub-0.8a34/ICMP.h
Hunk #1 FAILED at 43.
Hunk #2 FAILED at 54.
2 out of 2 hunks FAILED -- saving rejects to file
bro-pub-0.8a34/ICMP.h.rej


Maybe sending as attachment is better?

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH
Senior Security Analyst
netForensics -  http://www.netForensics.com
732-393-6071


From rpang at CS.Princeton.EDU  Fri Aug 22 14:25:39 2003
From: rpang at CS.Princeton.EDU (Ruoming Pang)
Date: Fri, 22 Aug 2003 17:25:39 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <Pine.LNX.4.56.0308221636210.24564@anton.netforensics.com>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.55.0308221408450.25949@willy.CS.Princeton.EDU>
 <Pine.LNX.4.56.0308221636210.24564@anton.netforensics.com>
Message-ID: <Pine.LNX.4.55.0308221723250.21242@willy.CS.Princeton.EDU>

Sorry. Please either use 'patch -l' (to ignore whitespace -- it worked for
me) or the attached patch file.

Ruoming

On Fri, 22 Aug 2003, Anton Chuvakin, Ph.D. wrote:

> >Below is a newer version of Robin's patch.
>
> [anton at bastion anton]$ patch -p0 < bro.patch
> patching file bro-pub-0.8a34/ICMP.cc
> Hunk #1 FAILED at 30.
> Hunk #2 FAILED at 83.
> Hunk #3 FAILED at 99.
> 3 out of 3 hunks FAILED -- saving rejects to file
> bro-pub-0.8a34/ICMP.cc.rej
> patching file bro-pub-0.8a34/ICMP.h
> Hunk #1 FAILED at 43.
> Hunk #2 FAILED at 54.
> 2 out of 2 hunks FAILED -- saving rejects to file
> bro-pub-0.8a34/ICMP.h.rej
>
>
> Maybe sending as attachment is better?
>
> Best,
> --
> Anton Chuvakin, Ph.D., GCIA, GCIH
> Senior Security Analyst
> netForensics -  http://www.netForensics.com
> 732-393-6071
>
-------------- next part --------------
diff -c bro-pub-0.8a34/ICMP.cc bro/ICMP.cc
*** bro-pub-0.8a34/ICMP.cc	Fri Aug 22 14:06:27 2003
--- bro/ICMP.cc	Fri Aug 22 11:04:22 2003
***************
*** 30,35 ****
--- 30,36 ----
  		const ConnID* id, const struct icmp* /* icmpp */)
  : Connection(s, k, t, id)
  	{
+ 	icmp_conn_val = 0;
  	}
  
  void ICMP_Connection::Done()
***************
*** 82,91 ****
  				int /* len */, int /* caplen */,
  				const u_char*& /* data */)
  	{
! 	Event(icmp_sent);
  	}
  
! void ICMP_Connection::Event(Func* f)
  	{
  	if ( ! f )
  		return;
--- 83,92 ----
  				int /* len */, int /* caplen */,
  				const u_char*& /* data */)
  	{
! 	ICMPEvent(icmp_sent);
  	}
  
! void ICMP_Connection::ICMPEvent(Func* f)
  	{
  	if ( ! f )
  		return;
***************
*** 98,116 ****
  
  RecordVal* ICMP_Connection::BuildICMPVal()
  	{
! 	if ( ! conn_val )
  		{
! 		conn_val = new RecordVal(icmp_conn);
  
! 		conn_val->Assign(0, new AddrVal(orig_addr));
! 		conn_val->Assign(1, new AddrVal(resp_addr));
! 		conn_val->Assign(2, new Val(type, TYPE_COUNT));
! 		conn_val->Assign(3, new Val(code, TYPE_COUNT));
  		}
  
! 	Ref(conn_val);
  
! 	return conn_val;
  	}
  
  int ICMP_Connection::IsReuse(double /* t */, const u_char* /* pkt */)
--- 99,117 ----
  
  RecordVal* ICMP_Connection::BuildICMPVal()
  	{
! 	if ( ! icmp_conn_val )
  		{
! 		icmp_conn_val = new RecordVal(icmp_conn);
  
! 		icmp_conn_val->Assign(0, new AddrVal(orig_addr));
! 		icmp_conn_val->Assign(1, new AddrVal(resp_addr));
! 		icmp_conn_val->Assign(2, new Val(type, TYPE_COUNT));
! 		icmp_conn_val->Assign(3, new Val(code, TYPE_COUNT));
  		}
  
! 	Ref(icmp_conn_val);
  
! 	return icmp_conn_val;
  	}
  
  int ICMP_Connection::IsReuse(double /* t */, const u_char* /* pkt */)
diff -c bro-pub-0.8a34/ICMP.h bro/ICMP.h
*** bro-pub-0.8a34/ICMP.h	Fri Aug 22 14:06:27 2003
--- bro/ICMP.h	Fri Aug 22 10:46:46 2003
***************
*** 43,49 ****
  
  	ConnectionType ConnType() const	{ return CONN_ICMP; }
  
! 	void Event(Func* f);
  
  	void Describe(ODesc* d) const;
  
--- 43,49 ----
  
  	ConnectionType ConnType() const	{ return CONN_ICMP; }
  
! 	void ICMPEvent(Func* f);
  
  	void Describe(ODesc* d) const;
  
***************
*** 54,59 ****
--- 54,60 ----
  	virtual void NextICMP(double t, const struct icmp* icmpp,
  				int len, int caplen, const u_char*& data);
  
+ 	RecordVal *icmp_conn_val;
  	int type;
  	int code;
  };

From anton at netForensics.com  Fri Aug 29 09:43:23 2003
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 29 Aug 2003 12:43:23 -0400 (EDT)
Subject: bro dies (every day)
In-Reply-To: <Pine.LNX.4.55.0308221723250.21242@willy.CS.Princeton.EDU>
References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de>
 <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk>
 <20030724083111.GA3240@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.56.0308220919110.20799@anton.netforensics.com> <3F46312B.1000604@lbl.gov>
 <20030822160339.GA25322@net.informatik.tu-muenchen.de>
 <Pine.LNX.4.55.0308221408450.25949@willy.CS.Princeton.EDU>
 <Pine.LNX.4.56.0308221636210.24564@anton.netforensics.com>
 <Pine.LNX.4.55.0308221723250.21242@willy.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.56.0308291242220.14263@anton.netforensics.com>

>Sorry. Please either use 'patch -l' (to ignore whitespace -- it worked for
>me) or the attached patch file.
This patch made bro much more stable and it didn't die in 5 days, BUT it
now spews thousand of "1061597578.544274 WeirdActivity ** non_IPv4_packet"
messages, all the time.

Any fixes for that?

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH
Senior Security Analyst
netForensics -  http://www.netForensics.com
732-393-6071