From pengxn at neusoft.com  Sun Dec  7 17:24:05 2003
From: pengxn at neusoft.com (Peng Xuena)
Date: Mon, 08 Dec 2003 09:24:05 +0800
Subject: how to install bro?
In-Reply-To: <200311170751.hAH7pJgB042342@jaguar.icir.org>
Message-ID: <CMENLEEEJKKGEKLPHHPBOEIACFAA.pengxn@neusoft.com>


hi, all:

	i am a new comer. i encountered difficulty when i install bro after compiling the source files. i use the command 'make install' after executing './configure' and 'make'. But 'make install "raised the error of 'Recursive variable 'INSTALL' references itself". I am wondering the way to resolve this problem, or any other ways of installing bro.
	thanks in advance!

Xuena Peng


From wsffree at hotmail.com  Sun Dec  7 18:46:00 2003
From: wsffree at hotmail.com (Wang Shaofu)
Date: Mon, 08 Dec 2003 10:46:00 +0800
Subject: how to install bro?
Message-ID: <Law12-F84z3IonZoRjP00017031@hotmail.com>

Just follow the intrusion:
./configure
./make
./bro
and you can see things done right


>From: Peng Xuena <pengxn at neusoft.com>
>To: c
>Subject: how to install bro?
>Date: Mon, 08 Dec 2003 09:24:05 +0800
>
>
>hi, all:
>
>	i am a new comer. i encountered difficulty when i install bro after 
compiling the source files. i use the command 'make install' after 
executing './configure' and 'make'. But 'make install "raised the error of 
'Recursive variable 'INSTALL' references itself". I am wondering the way to 
resolve this problem, or any other ways of installing bro.
>	thanks in advance!
>
>Xuena Peng

_________________________________________________________________
?????????????? MSN Messenger:  http://messenger.msn.com/cn  



From wsffree at hotmail.com  Sun Dec  7 19:25:15 2003
From: wsffree at hotmail.com (Wang Shaofu)
Date: Mon, 08 Dec 2003 11:25:15 +0800
Subject: =?gb2312?B?UkU6ILTwuLQ6IGhvdyB0byBpbnN0YWxsIGJybz8=?=
Message-ID: <Law12-F76UGXWteNsQL00017644@hotmail.com>

ps -a
can show u the procces include bro.


>
>yes, by this way i can use bro in an interactive way.
>The problem i am encountering now is that i don't know whether the engine 
is working or not, for i can't see any output after i executed "./bro -i 
eth0". And there's nothing logged when i use "./bro -i eth0 -w tmp.log".
>
>
>
>Just follow the intrusion:
>./configure
>./make
>./bro
>and you can see things done right
>
>
> >From: Peng Xuena <pengxn at neusoft.com>
> >To: c
> >Subject: how to install bro?
> >Date: Mon, 08 Dec 2003 09:24:05 +0800
> >
> >
> >hi, all:
> >
> >	i am a new comer. i encountered difficulty when i install bro after
>compiling the source files. i use the command 'make install' after
>executing './configure' and 'make'. But 'make install "raised the error of
>'Recursive variable 'INSTALL' references itself". I am wondering the way 
to
>resolve this problem, or any other ways of installing bro.
> >	thanks in advance!
> >
> >Xuena Peng
>
>_________________________________________________________________
>?????????????? MSN Messenger:  http://messenger.msn.com/cn
>

_________________________________________________________________
?????????????? MSN Messenger:  http://messenger.msn.com/cn  



From athomas at cc.gatech.edu  Sun Dec  7 19:53:38 2003
From: athomas at cc.gatech.edu (Ashley Thomas)
Date: Sun, 07 Dec 2003 22:53:38 -0500
Subject: =?GB2312?B?tPC4tDogaG93IHRvIGluc3RhbGwgYnJvPw==?=
In-Reply-To: <Law12-F76UGXWteNsQL00017644@hotmail.com>
References: <Law12-F76UGXWteNsQL00017644@hotmail.com>
Message-ID: <3FD3F5C2.1000101@cc.gatech.edu>

you also need to specify the policy file

./bro -i eth0 -w logfile mt.bro


Wang Shaofu wrote:

> ps -a
> can show u the procces include bro.
>
>
>>
>> yes, by this way i can use bro in an interactive way.
>> The problem i am encountering now is that i don't know whether the
>> engine 
>
> is working or not, for i can't see any output after i executed "./bro
> -i eth0". And there's nothing logged when i use "./bro -i eth0 -w
> tmp.log".
>
>>
>>
>>
>> Just follow the intrusion:
>> ./configure
>> ./make
>> ./bro
>> and you can see things done right
>>
>>
>> >From: Peng Xuena <pengxn at neusoft.com>
>> >To: c
>> >Subject: how to install bro?
>> >Date: Mon, 08 Dec 2003 09:24:05 +0800
>> >
>> >
>> >hi, all:
>> >
>> > i am a new comer. i encountered difficulty when i install bro after
>> compiling the source files. i use the command 'make install' after
>> executing './configure' and 'make'. But 'make install "raised the
>> error of
>> 'Recursive variable 'INSTALL' references itself". I am wondering the way 
>
> to
>
>> resolve this problem, or any other ways of installing bro.
>> > thanks in advance!
>> >
>> >Xuena Peng
>>
>> _________________________________________________________________
>> ?????????????? MSN Messenger: http://messenger.msn.com/cn
>>
>
> _________________________________________________________________
> ?????????????? MSN Messenger: http://messenger.msn.com/cn 





From vern at icir.org  Sun Dec  7 23:51:52 2003
From: vern at icir.org (Vern Paxson)
Date: Sun, 07 Dec 2003 23:51:52 -0800
Subject: how to install bro?
In-Reply-To: Your message of Mon, 08 Dec 2003 09:24:05 +0800.
Message-ID: <200312080751.hB87pqQx070969@jaguar.icir.org>

As always, when reporting Bro build problems you need to include the
platform on which you're trying to do the build.

> But 'make install "raised the error of 'Recursive variable 'INSTALL'
> references itself".

What is the value of INSTALL in the generated Makefile?

		Vern


From sommer at in.tum.de  Mon Dec  8 02:55:05 2003
From: sommer at in.tum.de (Robin Sommer)
Date: Mon, 8 Dec 2003 11:55:05 +0100
Subject: how to install bro?
In-Reply-To: <CMENLEEEJKKGEKLPHHPBOEIACFAA.pengxn@neusoft.com>
References: <200311170751.hAH7pJgB042342@jaguar.icir.org> <CMENLEEEJKKGEKLPHHPBOEIACFAA.pengxn@neusoft.com>
Message-ID: <20031208105505.GA28279@net.informatik.tu-muenchen.de>


On Mon, Dec 08, 2003 at 09:24 +0800, Peng Xuena wrote:

>    install "raised the error of 'Recursive variable 'INSTALL'

Try changing this line in Makefile.in 

    INSTALL = @INSTALL_PROGRAM@

to

    INSTALL = @INSTALL@

(and rerun configure).
    
There's an incompatiblity somewhere which causes this to fail on
some platforms, although I'm not sure where exactly it is.

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 --------------
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/20031208/4f19acd3/attachment.bin 

From vern at icir.org  Tue Dec  9 10:21:12 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 09 Dec 2003 10:21:12 -0800
Subject: new bro "CURRENT" release - 0.8a57
Message-ID: <200312091821.hB9ILCQx041017@jaguar.icir.org>

An updated "CURRENT" version of Bro is now available from the usual location:

	ftp://ftp.ee.lbl.gov/bro-pub-0.8-current.tar.gz

I've appended the changes between it and the last "CURRENT" version (0.8a48).

		Vern


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0.8a57 Tue Dec  9 10:14:30 PST 2003

- The format of Bro's connection summaries is changing.  The new format
  looks like

	  1069437569.904605 0.230644 1.2.3.4 5.6.7.8 http 59377 80 tcp 610 275 S3 L

  That is, <timestamp>, <duration>, <originator address>, <responder address>,
  <service>, <originator port>, <responder port>, <originator bytes>,
  <responder bytes>, <connection state>, <flags>.  (Robin Sommer)

  The script variable traditional_conn_format=T specifies to use the old
  format rather than this new one.  This is *currently* the default, but
  will change soon to default to F instead.  If you have comments on this
  new format, we'd like to hear them.

- The SigAction's available in signatures.bro have been extended (Robin Sommer).
  SIG_FILE_BUT_NO_SCAN is like SIG_FILE but without any horizontal/vertical
  processing; SIG_LOG_ONCE logs only an alert only the first time it occurs;
  SIG_LOG_PER_ORIG logs only the first instance of an alert generated by a
  particular originator; SIG_COUNT has been renamed SIG_COUNT_PER_RESP; and
  SIG_SUMMARY suppresses logging of individual alerts but generates a
  per-originator summary.

- A new -p option for snort2bro tells it to only process signatures that
  include matching on payload (Robin Sommer).

- You can now explicitly include or exclude particular SIDs when
  running snort2bro by specifying a configuration file via -c (Robin
  Sommer).  The format is simple, just "include" or "ignore" followed
  by the SID number:

	# sid-526 BAD TRAFFIC data in TCP SYN packet 
	ignore	526 

	# sid-623 matches a null-flags stealth scan.  Include it even
	# if we build with -p, since it doesn't tend to generate any
	# false positives.
	include	623

  The new "snort2bro.cfg" file gives examples (i.e., the above).

- Bro can now serialize functions and event handlers, meaning that these
  can be passed as values between Bro's and dumped using -g (Robin Sommer).
  One of the main goals in supporting this is to allow in situ alteration
  of the Bro's configuration (e.g., you can edit a function and change its
  functioning and have a running Bro pick up the change without having to
  stop and be restarted).  Such dynamic reconfiguration is experimentally
  supported via -g <dir> (see below).

- &persistent state is now stored in the *directory* given by state_dir
  (default: "./.state"), one file per variable, rather than a single file
  (Robin Sommer).

- Storing &persistent state to disk is now done incrementally: after writing
  each file, there's a delay of state_write_delay (default: 0.1 secs) before
  working on the next file (Robin Sommer). This may introduce small
  inconsistencies, but prevents load spikes that can lead to packet drops.
  Currently, there is no mechanism to incrementally store a single variable
  (like a large table), although there is already some framework in place
  to eventually support this.

- The *experimental* new -g <dir> option dumps the script-level configuration
  (excluding things defined in internal default scripts like bro.init)
  into the directory <dir>. These files may be printed with "bro -x <file>",
  or copied into the state_dir of a running Bro, which will then pick up
  the change if it has loaded checkpoint.bro.  (When picking up changes,
  event handlers are always added, while functions, types, and variables
  replace the current ones).

- Table values are now incrementally expired rather than all at once
  (Robin Sommer).  That is, if the expiration timer goes off and hundreds
  of values should now be expired, the work of doing so is spread over
  chunks of table_expire_size (default: 50) at a time, separated by a
  delay of table_expire_delay (default: 0.1 secs).  This change aims to
  prevent large processing spikes that can lead to packet drops.

- New built-ins sub() and gsub() act like awk's functions of the same
  name, changing substrings (either first, or all) that match a given
  regular expression to a given target string.  (Note, the calling sequence
  differs from the order used by awk.)

- The new auxiliary script aux/scripts/mvlog is a handy way to manage
  checkpointed logs.  See the script for documentation.

- The &expire_func function now takes two arguments.  The second is
  of type "any" and corresponds to the index(es) of the element being
  expired.  To access the individual indices, you use a new assignment form:

	[a, b, c] = index_val;

  (where index_val is the second argument of type "any").  This assigns
  a to the first index, b to the second, and c to the third.  NOTE: the
  use of "any" types here is *temporary* and will be changing in the
  future to a general "tuple" notion.  (Robin Sommer)

- scan.bro and conn.bro have been reworked to consume less memory and to
  support more flexible state expiration (Robin Sommer).

- The new builtin rescan_state() causes Bro to re-read any persistent
  data values (Robin Sommer).

- snort2bro now supports continued lines ("\<newline>") (Robin Sommer).

- The calling sequences of the software_version_found() and
  software_parse_error() events has changed, and a new event,
  software_unparsed_version_found(), is invoked for raw version
  strings (i.e., the version string prior to the event engine
  attempting to parse it into version/major/minor) (Robin Sommer).

- Software version tracking for clients now tracks all versions, not just
  the latest version (Robin Sommer).

- alert_info records now include an optional field event_src, which is the
  source of the event if it was received from an external Bro (Robin Sommer).

- Regular expressions now support {} iteration values of 0, and generate
  better error messages.

- Output generated by icmp.bro is now redirected into an "icmp" log file
  (Robin Sommer).

- autoconf tweaks for configuring OpenSSL on Linux (Ruoming Pang, Robin Sommer).
  Tested on RedHat (thanks to Anton Chuvakin), Debian, FreeBSD, Solaris.

- You can now turn off using OpenSSL even if the OS supports it, via
  configuring with --disable-openssl (Robin Sommer).

- Variable size computations (per global_sizes()) are now more accurate
  (Robin Sommer).

- A bug with combining file encryption and log rotation has been
  fixed (Robin Sommer).

- A problem tracking directionality in signatures fixed (Robin Sommer).

- Bro now continues running if DNS is not functioning (Robin Sommer).

- Rewriter memory use has been significantly reduced (Ruoming Pang).

- Some bugs with -A/-w interaction have been fixed (Ruoming Pang).


From vern at icir.org  Tue Dec  9 10:39:47 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 09 Dec 2003 10:39:47 -0800
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release - 0.8a57)
Message-ID: <200312091839.hB9IdlQx043298@jaguar.icir.org>

Argh - the 0.8a57 release uses some new libpcap functionality
(pcap_compile_nocap(), and calling pcap_freecode() with a bpf_program*)
that isn't supported in older libpcap releases.  If someone could please
contribute autoconf tweaks to deal with this incompatibility, I'd much
appreciate it.

		Vern


From million_visitors at yahoo.com  Tue Dec  9 15:08:35 2003
From: million_visitors at yahoo.com (Kate Porter)
Date: Tue Dec 09 16:08:35 MST 2003
Subject: Your Confirmation
Message-ID: <200312092308.hB9N8dMC014825@postal2.lbl.gov>

An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20031209/33676f88/attachment.html 

From christian at whoop.org  Wed Dec 10 07:35:28 2003
From: christian at whoop.org (Christian Kreibich)
Date: 10 Dec 2003 15:35:28 +0000
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release -
	0.8a57)
In-Reply-To: <200312091839.hB9IdlQx043298@jaguar.icir.org>
References: <200312091839.hB9IdlQx043298@jaguar.icir.org>
Message-ID: <1071070528.3805.92.camel@ghouls.cl.cam.ac.uk>

Hi all,

On Tue, 2003-12-09 at 18:39, Vern Paxson wrote:
> Argh - the 0.8a57 release uses some new libpcap functionality
> (pcap_compile_nocap(), and calling pcap_freecode() with a bpf_program*)
> that isn't supported in older libpcap releases.  If someone could please
> contribute autoconf tweaks to deal with this incompatibility, I'd much
> appreciate it.

mhmm ... it seems that pcap_compile_nopcap() was added in 0.5, and
pcap_freecode() without the pcap_t in 0.6.1, so I guess there should be
a check for versions >= 0.6.1.

I'm attaching a patch that seems to work -- it checks whether the
pcap_compile_nocap symbol exists, and whether a program passing only one
argument to pcap_freecode() can build.

I haven't checked if the autoconf macros are available in older versions
as well (at that point I'm usually losing my patience :) Apply with -p0
in the toplevel directory of the source tree.

Hth,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org
-------------- next part --------------
--- configure.ac        Wed Dec 10 15:01:12 2003
+++ configure.ac.new    Wed Dec 10 15:24:44 2003
@@ -174,6 +174,22 @@

 dnl Checks for library functions.
 AC_LBL_LIBPCAP(V_PCAPDEP, V_INCLS)
+echo
+
+dnl On top of the LBL check, we need to make sure that
+dnl we have pcap_compile_nopcap() and pcap_freecode(struct bpf_program *).
+AC_CHECK_LIB(pcap, pcap_compile_nopcap, [],
+   AC_MSG_ERROR([Please use at least libpcap version 0.6.1]),
+   [-lpcap]
+)
+AC_MSG_CHECKING([if pcap provides pcap_freecode(struct bpf_program *)])
+AC_COMPILE_IFELSE(
+   AC_LANG_PROGRAM([#include <pcap.h>], [ int main() { pcap_freecode(NULL); } ]),
+   AC_MSG_RESULT(yes),
+   AC_MSG_RESULT(no)
+   AC_MSG_ERROR([Please use at least libpcap version 0.6.1])
+)
+
 AC_CHECK_FUNCS(bpf_set_bufsize)
 AC_FUNC_MEMCMP
 AC_FUNC_STRFTIME

From christian at whoop.org  Wed Dec 10 07:37:39 2003
From: christian at whoop.org (Christian Kreibich)
Date: 10 Dec 2003 15:37:39 +0000
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release -
	0.8a57)
In-Reply-To: <1071070528.3805.92.camel@ghouls.cl.cam.ac.uk>
References: <200312091839.hB9IdlQx043298@jaguar.icir.org>
	 <1071070528.3805.92.camel@ghouls.cl.cam.ac.uk>
Message-ID: <1071070659.3805.95.camel@ghouls.cl.cam.ac.uk>

On Wed, 2003-12-10 at 15:35, Christian Kreibich wrote:
> Hi all,
> 
> On Tue, 2003-12-09 at 18:39, Vern Paxson wrote:
> > Argh - the 0.8a57 release uses some new libpcap functionality
> > (pcap_compile_nocap(), and calling pcap_freecode() with a bpf_program*)
> > that isn't supported in older libpcap releases.  If someone could please
> > contribute autoconf tweaks to deal with this incompatibility, I'd much
> > appreciate it.
> 
> mhmm ... it seems that pcap_compile_nopcap() was added in 0.5, and
> pcap_freecode() without the pcap_t in 0.6.1, so I guess there should be
> a check for versions >= 0.6.1.
> 
> I'm attaching a patch that seems to work -- it checks whether the
> pcap_compile_nocap symbol exists, and whether a program passing only one
               ^^^^^
Heh. I duplicated the typo :) The patch *does* check for
pcap_compile_nopcap() though ...

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org



From anton at netForensics.com  Fri Dec 12 07:52:06 2003
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 12 Dec 2003 10:52:06 -0500 (EST)
Subject: Bro 57 segfaults
In-Reply-To: <200312091839.hB9IdlQx043298@jaguar.icir.org>
References: <200312091839.hB9IdlQx043298@jaguar.icir.org>
Message-ID: <Pine.LNX.4.58.0312121049440.11085@anton.netforensics.com>

All,

I just build and deployed bro-0.8a57 and the thing segfaults after about
5-100 minutes of running. I tried '-t file', but then it segfaults
immediately.

Platform is RedHat 9; default build of bro with ssl. Deployed on a fairly
loaded 10MB/s link.

Anybody else seeing this?

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


From mtdedlow at lbl.gov  Fri Dec 12 10:03:15 2003
From: mtdedlow at lbl.gov (Mark Dedlow)
Date: Fri, 12 Dec 2003 10:03:15 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: <200312091821.hB9ILCQx041017@jaguar.icir.org>
References: <200312091821.hB9ILCQx041017@jaguar.icir.org>
Message-ID: <3FDA02E3.9090209@lbl.gov>


> - The format of Bro's connection summaries is changing.  The new format
>   looks like
> 
> 	  1069437569.904605 0.230644 1.2.3.4 5.6.7.8 http 59377 80 tcp 610 275 S3 L
> 
>   That is, <timestamp>, <duration>, <originator address>, <responder address>,
>   <service>, <originator port>, <responder port>, <originator bytes>,
>   <responder bytes>, <connection state>, <flags>.  (Robin Sommer)
> 
>   The script variable traditional_conn_format=T specifies to use the old
>   format rather than this new one.  This is *currently* the default, but
>   will change soon to default to F instead.  If you have comments on this
>   new format, we'd like to hear them.

The changes notes above don't mention the <addl> field.  Is that just
an oversight in the notes, or is it being droppped from the red log?

Will <service> still contain port numbers?  Or will "other-nnnnn" become
simply "other"?  (that would be my preference)

Although I don't know what the "neighbor net" U flag even means, I wonder
if this is the time to drop that, as the BRO manual says the whole notion
is historical.


Mark





From vern at icir.org  Fri Dec 12 10:51:32 2003
From: vern at icir.org (Vern Paxson)
Date: Fri, 12 Dec 2003 10:51:32 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: Your message of Fri, 12 Dec 2003 10:03:15 PST.
Message-ID: <200312121851.hBCIpWQx015308@jaguar.icir.org>

> The changes notes above don't mention the <addl> field.  Is that just
> an oversight in the notes,

Yes, just an oversight in the notes.

> Will <service> still contain port numbers?  Or will "other-nnnnn" become
> simply "other"?  (that would be my preference)

Good point.  As implemented, it continues to be other-nnnnn, but I think
just plain "other" makes more sense, since we now can finally cleanly separate
the notion of service from the notion of port.

> Although I don't know what the "neighbor net" U flag even means, I wonder
> if this is the time to drop that, as the BRO manual says the whole notion
> is historical.

The notion of "neighbor" is still used a bit in the policy scripts
(in scan.bro, in particular - different rules apply to scan detection
for activity from neighbors than from others), but arguably this should
be structured in a different fashion (a general notion of networks that
are allowed to scan), and in fact this has bitten us operationally in
the past, when a infected neighbor scanned us.

Thanks for the suggestions!

		Vern


From mtdedlow at lbl.gov  Fri Dec 12 11:27:51 2003
From: mtdedlow at lbl.gov (Mark Dedlow)
Date: Fri, 12 Dec 2003 11:27:51 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: <200312121851.hBCIpWQx015308@jaguar.icir.org>
References: <200312121851.hBCIpWQx015308@jaguar.icir.org>
Message-ID: <3FDA16B7.9080604@lbl.gov>


>>Will <service> still contain port numbers?  Or will "other-nnnnn" become
>>simply "other"?  (that would be my preference)
> 
> 
> Good point.  As implemented, it continues to be other-nnnnn, but I think
> just plain "other" makes more sense, since we now can finally cleanly separate
> the notion of service from the notion of port.

It's cleaner, but is it really separated internally, or just in the logs?
I confess (and probably reveal) my near total BRO ignorance, but isn't
service just mapped from port number in some (many?) cases?  Even if
so, the separation is valuable and clearly necessary where not so,
but I wonder if it wouldn't be useful to have some indication of those
connections that BRO has determined the service of (via inspection)
versus merely inferring the service from a port:name lookup table.

Put another way (my interest), it's my impression that sometimes the
service field contains additional information and sometimes it doesn't.
Is that correct?  If so, would indicating this in the log be worthwhile?

Mark

PS. any consideration of making the log format a config spec:

red_log_format: "%time %duration %service %oip %rip %bytes %rbytes ...."

maybe little value... just a thought.




From christian at whoop.org  Mon Dec 15 06:20:06 2003
From: christian at whoop.org (Christian Kreibich)
Date: 15 Dec 2003 14:20:06 +0000
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release -
	0.8a57)
In-Reply-To: <200312091839.hB9IdlQx043298@jaguar.icir.org>
References: <200312091839.hB9IdlQx043298@jaguar.icir.org>
Message-ID: <1071498006.4435.120.camel@ghouls.cl.cam.ac.uk>

Hi,

On Tue, 2003-12-09 at 18:39, Vern Paxson wrote:
> Argh - the 0.8a57 release uses some new libpcap functionality
> (pcap_compile_nocap(), and calling pcap_freecode() with a bpf_program*)
> that isn't supported in older libpcap releases.  If someone could please
> contribute autoconf tweaks to deal with this incompatibility, I'd much
> appreciate it.

is Bro supported on NetBSD? If so, a recent thread on ethereal-dev
discussed pcap_compile_nopcap() in that context and might be relevant
for Bro. Have a look at

http://www.ethereal.com/lists/ethereal-dev/200312/msg00401.html

Best,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org



From vern at icir.org  Tue Dec 16 09:02:55 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 09:02:55 -0800
Subject: new bro "CURRENT" release - 0.8a58
Message-ID: <200312161702.hBGH2tBZ040978@jaguar.icir.org>

An updated "CURRENT" version of Bro is now available from the usual location:

	ftp://ftp.ee.lbl.gov/bro-pub-0.8-current.tar.gz

The only change is compatibility with older versions of libpcap,
contributed by Chema Gonzalez.  Patch appended.

		Vern


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/CHANGES bro-pub-0.8a58/CHANGES
--- bro-pub-0.8a57/CHANGES	Thu Dec  4 17:24:03 2003
+++ bro-pub-0.8a58/CHANGES	Tue Dec 16 08:57:25 2003
@@ -2,6 +2,13 @@
 
 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
+
+0.8a58 Tue Dec 16 08:55:47 PST 2003
+
+- Compatibility with older versions of libpcap (Chema Gonzalez).
+
+
+0.8a57 Tue Dec  9 10:14:30 PST 2003
 
 - The format of Bro's connection summaries is changing.  The new format
   looks like
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/PktSrc.cc bro-pub-0.8a58/PktSrc.cc
--- bro-pub-0.8a57/PktSrc.cc	Tue Oct 21 12:21:01 2003
+++ bro-pub-0.8a58/PktSrc.cc	Tue Dec 16 08:55:36 2003
@@ -106,7 +106,11 @@
 	bpf_program* oldcode = (bpf_program*) filters.Lookup(hash);
 	if ( oldcode )
 		{
+#ifndef DONT_HAVE_LIBPCAP_PCAP_FREECODE
 		pcap_freecode(oldcode);
+#else
+		pcap_freecode(NULL, oldcode);
+#endif
 		delete oldcode;
 		}
 
@@ -328,3 +332,58 @@
 	{
 	delete program->bf_insns;
 	}
+
+
+
+#ifdef DONT_HAVE_LIBPCAP_PCAP_FREECODE
+extern "C" {
+#include "pcap-int.h"
+
+int pcap_freecode(pcap_t* unused, struct bpf_program* program)
+	{
+	program->bf_len = 0;
+
+	if ( program->bf_insns )
+		{
+		free((char*) program->bf_insns);
+		program->bf_insns = 0;
+		}
+
+	return 0;
+	}
+
+pcap_t* pcap_open_dead(int linktype, int snaplen)
+	{
+	pcap_t* p;
+
+	p = (pcap_t*) malloc(sizeof(*p));
+	if ( ! p )
+		return 0;
+
+	memset(p, 0, sizeof(*p));
+
+	p->fd = -1;
+	p->snapshot = snaplen;
+	p->linktype = linktype;
+
+	return p;
+	}
+
+int pcap_compile_nopcap(int snaplen_arg, int linktype_arg,
+			struct bpf_program* program, char* buf,
+			int optimize, bpf_u_int32 mask)
+	{
+	pcap_t* p;
+	int ret;
+
+	p = pcap_open_dead(linktype_arg, snaplen_arg);
+	if ( ! p )
+		return -1;
+
+	ret = pcap_compile(p, program, buf, optimize, mask);
+	pcap_close(p);
+
+	return ret;
+	}   
+}
+#endif
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/PktSrc.h bro-pub-0.8a58/PktSrc.h
--- bro-pub-0.8a57/PktSrc.h	Tue Oct 21 12:20:41 2003
+++ bro-pub-0.8a58/PktSrc.h	Tue Dec 16 08:55:36 2003
@@ -186,5 +186,13 @@
 	PktFileSrc(const char* readfile, const char* filter, 
 			PktSrc_Filter_Type ft=TYPE_FILTER_NORMAL);
 };
+
+#ifdef DONT_HAVE_LIBPCAP_PCAP_FREECODE
+extern "C" {
+	int pcap_freecode(pcap_t*, struct bpf_program*);
+	int pcap_compile_nopcap(int, int, struct bpf_program*,
+			char*, int, bpf_u_int32);
+}
+#endif
 
 #endif
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/VERSION bro-pub-0.8a58/VERSION
--- bro-pub-0.8a57/VERSION	Thu Dec  4 15:13:05 2003
+++ bro-pub-0.8a58/VERSION	Thu Dec 11 17:20:52 2003
@@ -1,1 +1,1 @@
-0.8a57
+0.8a58
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/config.h.in bro-pub-0.8a58/config.h.in
--- bro-pub-0.8a57/config.h.in	Tue Nov 18 23:27:19 2003
+++ bro-pub-0.8a58/config.h.in	Thu Dec 11 17:21:20 2003
@@ -6,6 +6,10 @@
 /* enable IPV6 processing */
 #undef BROv6
 
+/* Old libpcap versions (< 0.6.1) need defining pcap_freecode and
+   pcap_compile_nopcap */
+#undef DONT_HAVE_LIBPCAP_PCAP_FREECODE
+
 /* should explicitly declare socket() and friends */
 #undef DO_SOCK_DECL
 
@@ -26,6 +30,9 @@
 
 /* Define to 1 if you have the `nsl' library (-lnsl). */
 #undef HAVE_LIBNSL
+
+/* Define to 1 if you have the `pcap' library (-lpcap). */
+#undef HAVE_LIBPCAP
 
 /* Define to 1 if you have the `resolv' library (-lresolv). */
 #undef HAVE_LIBRESOLV
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/configure bro-pub-0.8a58/configure
--- bro-pub-0.8a57/configure	Tue Nov 18 23:27:02 2003
+++ bro-pub-0.8a58/configure	Thu Dec 11 17:24:35 2003
@@ -6051,7 +6051,80 @@
 echo "${ECHO_T}$libpcap" >&6
     fi
     if test "x$libpcap" != "x-lpcap" ; then
-	    LIBS="$libpcap $LIBS"
+      LIBS="-L$d -lpcap $LIBS"
+    fi
+
+
+echo "$as_me:$LINENO: checking for pcap_freecode in -lpcap" >&5
+echo $ECHO_N "checking for pcap_freecode in -lpcap... $ECHO_C" >&6
+if test "${ac_cv_lib_pcap_pcap_freecode+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lpcap  $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char pcap_freecode ();
+int
+main ()
+{
+pcap_freecode ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_lib_pcap_pcap_freecode=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_pcap_pcap_freecode=no
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_pcap_pcap_freecode" >&5
+echo "${ECHO_T}$ac_cv_lib_pcap_pcap_freecode" >&6
+if test $ac_cv_lib_pcap_pcap_freecode = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBPCAP 1
+_ACEOF
+
+  LIBS="-lpcap $LIBS"
+
+fi
+
+    if test "$ac_cv_lib_pcap_pcap_freecode" = no ; then
+	    unset ac_cv_lib_pcap_pcap_freecode
+
+cat >>confdefs.h <<\_ACEOF
+#define DONT_HAVE_LIBPCAP_PCAP_FREECODE
+_ACEOF
+
     fi
 
 		    echo "$as_me:$LINENO: checking for pcap headers" >&5
diff -wcr --ignore-matching-lines=Id: bro-pub-0.8a57/lbl-aclocal.m4 bro-pub-0.8a58/lbl-aclocal.m4
--- bro-pub-0.8a57/lbl-aclocal.m4	Wed Sep  3 23:04:40 2003
+++ bro-pub-0.8a58/lbl-aclocal.m4	Tue Dec 16 08:55:37 2003
@@ -240,7 +240,14 @@
 	    AC_MSG_RESULT($libpcap)
     fi
     if test "x$libpcap" != "x-lpcap" ; then
-	    LIBS="$libpcap $LIBS"
+      LIBS="-L$d -lpcap $LIBS"
+    fi
+
+    dnl check libpcap is modern enough for Bro (>= 0.6.1)
+    AC_CHECK_LIB(pcap, pcap_freecode)
+    if test "$ac_cv_lib_pcap_pcap_freecode" = no ; then
+	    unset ac_cv_lib_pcap_pcap_freecode
+	    AC_DEFINE([DONT_HAVE_LIBPCAP_PCAP_FREECODE],[],[Old libpcap versions (< 0.6.1) need defining pcap_freecode and pcap_compile_nopcap])
     fi
 
 		dnl check pcap headers location


From vern at icir.org  Tue Dec 16 09:08:44 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 09:08:44 -0800
Subject: Serious problem running bro-pub-0.8a48 on OpenBSD 3.3
In-Reply-To: Your message of Mon, 10 Nov 2003 12:24:03 EST.
Message-ID: <200312161708.hBGH8iBZ041556@jaguar.icir.org>

My apologies for dropping the ball on this thread :-(.

> -  I am running this on a P3-600 MHz, 200 MB memory system. Is that too 
> slow?

It crticially depends on your traffic volume.  In my experience, a machine
like that should be able to monitor a network on the order of a hundred
machines with a 100 Mbps link; but that's somewhat a guess, as most of my
experience is with bigger/faster networks.

> - The size of the 'bro.core' file upon the seg-fault is of the order of 500 
> MB.
> Isn't that weird?

This very likely indicates that Bro is crashing because you've reached
the process "datasize" limit.  See what "limit datasize" reports.

> The response time of my system also increases drastically

That's because, given 200 MB of real memory, when Bro grows beyond that
towards 500 MB, you suffer a great deal of paging.

It appears very likely that you are encountering a memory leak.
Try (1) running the latest release (I just announced 0.8a58),
and, if the problem persists, turning on memory statistics, which
you can do by including "statistics.bro" as a policy script on the
command line or via @load.

		Vern


From vern at icir.org  Tue Dec 16 09:12:12 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 09:12:12 -0800
Subject: Bro 57 segfaults
In-Reply-To: Your message of Fri, 12 Dec 2003 10:52:06 EST.
Message-ID: <200312161712.hBGHCCBZ041896@jaguar.icir.org>

> I just build and deployed bro-0.8a57 and the thing segfaults after about
> 5-100 minutes of running. I tried '-t file', but then it segfaults
> immediately.
> 
> Platform is RedHat 9; default build of bro with ssl. Deployed on a fairly
> loaded 10MB/s link.
> 
> Anybody else seeing this?

I don't run in that environment, but Robin does (or in something similar),
and I don't believe he's encountered any problems recently.

In general, when reporting a Bro crash, it helps a lot to show a traceback
(not -t output, which is generally much to voluminous to aid in debugging
crashes).  Better (much) still is a tcpdump trace that reprodouces the
problem, if you're able to give me a copy of such.

Note, I recently ran across a problem running Bro's signature engine
against UDP or ICMP traffic.  By default, each new UDP/ICMP flow sticks
around forever, so this rapidly consumes a huge amount of memory.  You
can eliminate the problem via "@load reduce-memory".

		Vern


From vern at icir.org  Tue Dec 16 09:13:14 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 09:13:14 -0800
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release - 0.8a57)
In-Reply-To: Your message of 15 Dec 2003 14:20:06 GMT.
Message-ID: <200312161713.hBGHDEBZ041963@jaguar.icir.org>

> is Bro supported on NetBSD?

Not directly, since we don't have any NetBSD machines in house, but
it's certainly the intent that it runs under NetBSD (and in general
on systems with libpcap), if it's not too painful.

> If so, a recent thread on ethereal-dev
> discussed pcap_compile_nopcap() in that context and might be relevant
> for Bro. Have a look at
> 
> http://www.ethereal.com/lists/ethereal-dev/200312/msg00401.html

Looks like some more autoconf'ing will be needed :-(.  If someone cares
to contribute it, that would be great.

		Vern


From vern at icir.org  Tue Dec 16 09:21:11 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 09:21:11 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: Your message of Fri, 12 Dec 2003 11:27:51 PST.
Message-ID: <200312161721.hBGHLBBZ042684@jaguar.icir.org>

> > Good point.  As implemented, it continues to be other-nnnnn, but I think
> > just plain "other" makes more sense, since we now can finally cleanly separate
> > the notion of service from the notion of port.
> 
> It's cleaner, but is it really separated internally, or just in the logs?

The notion of "service" is "what is the actual service [application] running
on the connection".  It initially arose from the utility of associating
"ftp-data" with connections that otherwise might not be identified as such,
since they didn't use well-known ports.

Bro is moving towards more fully decoupling the notion of what application
protocol to analyze vs. what application is usually associated with a given
well-known port, so I think the split of service in the connection logs
will be helpful in this regard.

> I confess (and probably reveal) my near total BRO ignorance, but isn't
> service just mapped from port number in some (many?) cases?

In most cases, yes, but not in all.

> Even if
> so, the separation is valuable and clearly necessary where not so,
> but I wonder if it wouldn't be useful to have some indication of those
> connections that BRO has determined the service of (via inspection)
> versus merely inferring the service from a port:name lookup table.

Hmmmm, perhaps this should be a new flag (to go along with 'L', and
the soon-to-depart 'U'), but I'm not sure it's worth it - do you have
an example in which this is particularly handy to have?

> PS. any consideration of making the log format a config spec:
> 
> red_log_format: "%time %duration %service %oip %rip %bytes %rbytes ...."
> 
> maybe little value... just a thought.

I think a better way to do this is to make it easy for the user to supply
their own connection log printer directly.

		Vern


From vern at icir.org  Tue Dec 16 14:17:50 2003
From: vern at icir.org (Vern Paxson)
Date: Tue, 16 Dec 2003 14:17:50 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: Your message of Tue, 16 Dec 2003 14:12:16 PST.
Message-ID: <200312162217.hBGMHoBZ055980@jaguar.icir.org>

> For example, what if I run some proprietary service on port 80?
> Is is going to be service 'other' or service 'http'?  What if
> I run telnetd on port 80?

Currently, this will be identified as "http".

Bro's TCP analyzers are being reworked so that in the future it will be
able to run alternate (or multiple) analyzers from that associated with
the well-known port.  When that works, I think the above example would
have "telnet" as the service even though the responder port would be 80/tcp.

		Vern


From mtdedlow at lbl.gov  Tue Dec 16 14:12:16 2003
From: mtdedlow at lbl.gov (Mark Dedlow)
Date: Tue, 16 Dec 2003 14:12:16 -0800
Subject: new bro "CURRENT" release - 0.8a57
In-Reply-To: <200312161721.hBGHLBBZ042684@jaguar.icir.org>
References: <200312161721.hBGHLBBZ042684@jaguar.icir.org>
Message-ID: <3FDF8340.7040701@lbl.gov>


>>but I wonder if it wouldn't be useful to have some indication of those
>>connections that BRO has determined the service of (via inspection)
>>versus merely inferring the service from a port:name lookup table.
> 
> 
> Hmmmm, perhaps this should be a new flag (to go along with 'L', and
> the soon-to-depart 'U'), but I'm not sure it's worth it - do you have
> an example in which this is particularly handy to have?

I'm sort of thinking about identifying non-standard port usage.
For example, what if I run some proprietary service on port 80?
Is is going to be service 'other' or service 'http'?  What if
I run telnetd on port 80?

I'm just thinking of the distinction between positive knowledge
of a service vs. inference of service by port number.

Mark




From chema at cs.berkeley.edu  Tue Dec 16 15:15:52 2003
From: chema at cs.berkeley.edu (=?iso-8859-1?Q?Jos=E9=20Mar=EDa=20Gonz=E1lez?=)
Date: Tue, 16 Dec 2003 15:15:52 -0800
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release - 
 0.8a57)
References: <200312161713.hBGHDEBZ041963@jaguar.icir.org>
Message-ID: <3FDF9228.1B7F81E5@cs.berkeley.edu>

Hi, 

This patch should recognize how many parameters 
pcap_compile_nopcap needs. 

Can somebody with a NetBSD box try it? 

-Chema




Vern Paxson wrote:
> 
> > is Bro supported on NetBSD?
> 
> Not directly, since we don't have any NetBSD machines in house, but
> it's certainly the intent that it runs under NetBSD (and in general
> on systems with libpcap), if it's not too painful.
> 
> > If so, a recent thread on ethereal-dev
> > discussed pcap_compile_nopcap() in that context and might be relevant
> > for Bro. Have a look at
> >
> > http://www.ethereal.com/lists/ethereal-dev/200312/msg00401.html
> 
> Looks like some more autoconf'ing will be needed :-(.  If someone cares
> to contribute it, that would be great.
> 
>                 Vern
-------------- next part --------------
diff -Naur ./bro-pub-0.8a58.orig/config.h.in bro-pub-0.8a58/config.h.in
--- ./bro-pub-0.8a58.orig/config.h.in	Thu Dec 11 17:21:20 2003
+++ bro-pub-0.8a58/config.h.in	Tue Dec 16 15:13:24 2003
@@ -112,6 +112,10 @@
 /* Define to 1 if you have the <unistd.h> header file. */
 #undef HAVE_UNISTD_H
 
+/* Some libpcap versions use an extra parameter (error) in pcap_compile_nopcap
+   */
+#undef LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
+
 /* Include krb5.h */
 #undef NEED_KRB5_H
 
diff -Naur ./bro-pub-0.8a58.orig/configure bro-pub-0.8a58/configure
--- ./bro-pub-0.8a58.orig/configure	Thu Dec 11 17:24:35 2003
+++ bro-pub-0.8a58/configure	Tue Dec 16 15:17:57 2003
@@ -6154,6 +6154,131 @@
 	    V_INCLS="$V_INCLS -I$pcap_includes"
     fi
 
+				CFLAGS="$CFLAGS -I$pcap_includes"
+		echo "$as_me:$LINENO: checking if pcap_compile_nopcap needs error parameter" >&5
+echo $ECHO_N "checking if pcap_compile_nopcap needs error parameter... $ECHO_C" >&6
+		cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+				#include <pcap.h>
+
+int
+main ()
+{
+
+				int snaplen;
+				int linktype;
+				struct bpf_program fp;
+				int optimize;
+				bpf_u_int32 netmask;
+				char str[10];
+				snaplen = 50;
+				linktype = DLT_EN10MB;
+				optimize = 1;
+				netmask = 0L;
+				str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+				(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  result="ok"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+result="wrong"
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+		if test "$result" = "ok" ; then
+			echo "$as_me:$LINENO: result: not needed" >&5
+echo "${ECHO_T}not needed" >&6
+		else
+			cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+					#include <pcap.h>
+
+int
+main ()
+{
+
+					int snaplen;
+					int linktype;
+					struct bpf_program fp;
+					int optimize;
+					bpf_u_int32 netmask;
+					char str[10];
+					char error[1024];
+					snaplen = 50;
+					linktype = DLT_EN10MB;
+					optimize = 1;
+					netmask = 0L;
+					str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+					(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask, &error);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  result="ok"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+result="wrong"
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+			if test "$result" = "ok" ; then
+
+cat >>confdefs.h <<\_ACEOF
+#define LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
+_ACEOF
+
+				echo "$as_me:$LINENO: result: needed" >&5
+echo "${ECHO_T}needed" >&6
+			else
+				{ { echo "$as_me:$LINENO: error: don't know (weird pcap_compile_nopcap)" >&5
+echo "$as_me: error: don't know (weird pcap_compile_nopcap)" >&2;}
+   { (exit 1); exit 1; }; }
+			fi
+		fi
+
 
     case "$target_os" in
 
diff -Naur ./bro-pub-0.8a58.orig/lbl-aclocal.m4 bro-pub-0.8a58/lbl-aclocal.m4
--- ./bro-pub-0.8a58.orig/lbl-aclocal.m4	Tue Dec 16 08:55:37 2003
+++ bro-pub-0.8a58/lbl-aclocal.m4	Tue Dec 16 15:17:50 2003
@@ -274,6 +274,56 @@
 	    V_INCLS="$V_INCLS -I$pcap_includes"
     fi
 
+		dnl check if pcap_compile_nopcap needs error parameter (NetBSDism)
+		CFLAGS="$CFLAGS -I$pcap_includes"
+		AC_MSG_CHECKING(if pcap_compile_nopcap needs error parameter)
+		AC_LINK_IFELSE(
+			[AC_LANG_PROGRAM([[
+				#include <pcap.h>
+				]], [[
+				int snaplen;
+				int linktype;
+				struct bpf_program fp;
+				int optimize;
+				bpf_u_int32 netmask;
+				char str[10];
+				snaplen = 50;
+				linktype = DLT_EN10MB;
+				optimize = 1;
+				netmask = 0L;
+				str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+				(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask);
+				]])],result="ok",result="wrong")
+		if test "$result" = "ok" ; then
+			AC_MSG_RESULT(not needed)
+		else
+			AC_LINK_IFELSE(
+				[AC_LANG_PROGRAM([[
+					#include <pcap.h>
+					]], [[
+					int snaplen;
+					int linktype;
+					struct bpf_program fp;
+					int optimize;
+					bpf_u_int32 netmask;
+					char str[10];
+					char error[1024];
+					snaplen = 50;
+					linktype = DLT_EN10MB;
+					optimize = 1;
+					netmask = 0L;
+					str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+					(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask, &error);
+					]])],result="ok",result="wrong")
+			if test "$result" = "ok" ; then
+				AC_DEFINE([LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER],[],
+						[Some libpcap versions use an extra parameter (error) in pcap_compile_nopcap])
+				AC_MSG_RESULT(needed)
+			else
+				AC_MSG_ERROR(don't know (weird pcap_compile_nopcap))
+			fi
+		fi
+
 
     case "$target_os" in
 

From chema at cs.berkeley.edu  Tue Dec 16 15:23:45 2003
From: chema at cs.berkeley.edu (=?iso-8859-1?Q?Jos=E9=20Mar=EDa=20Gonz=E1lez?=)
Date: Tue, 16 Dec 2003 15:23:45 -0800
Subject: libpcap compatibility problem (Re: new bro "CURRENT" release - 
 0.8a57)
References: <200312161713.hBGHDEBZ041963@jaguar.icir.org> <3FDF9228.1B7F81E5@cs.berkeley.edu>
Message-ID: <3FDF9401.2EE8FCEF@cs.berkeley.edu>

Yups, incomplete patch. 

This is the complete one. 

-Chema



Jos? Mar?a Gonz?lez wrote:
> 
> Hi,
> 
> This patch should recognize how many parameters
> pcap_compile_nopcap needs.
> 
> Can somebody with a NetBSD box try it?
> 
> -Chema
-------------- next part --------------
diff -Naur ./bro-pub-0.8a58.orig/PktSrc.cc bro-pub-0.8a58/PktSrc.cc
--- ./bro-pub-0.8a58.orig/PktSrc.cc	Tue Dec 16 08:55:36 2003
+++ bro-pub-0.8a58/PktSrc.cc	Tue Dec 16 15:24:43 2003
@@ -188,8 +188,14 @@
 		SecondaryEvent* se = secondary_path->EventTable()[i];
 		program = new struct bpf_program;
 
+#ifndef LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
 		int i = pcap_compile_nopcap(snaplen, datalink, program,
 				(char*) (se->Filter()), 1, netmask);
+#else
+		char error[1024];
+		int i = pcap_compile_nopcap(snaplen, datalink, program,
+				(char*) (se->Filter()), 1, netmask, &error);
+#endif
 		if ( i < 0 )
 			{
 			snprintf(errbuf, sizeof(errbuf),
diff -Naur ./bro-pub-0.8a58.orig/config.h.in bro-pub-0.8a58/config.h.in
--- ./bro-pub-0.8a58.orig/config.h.in	Thu Dec 11 17:21:20 2003
+++ bro-pub-0.8a58/config.h.in	Tue Dec 16 15:13:24 2003
@@ -112,6 +112,10 @@
 /* Define to 1 if you have the <unistd.h> header file. */
 #undef HAVE_UNISTD_H
 
+/* Some libpcap versions use an extra parameter (error) in pcap_compile_nopcap
+   */
+#undef LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
+
 /* Include krb5.h */
 #undef NEED_KRB5_H
 
diff -Naur ./bro-pub-0.8a58.orig/configure bro-pub-0.8a58/configure
--- ./bro-pub-0.8a58.orig/configure	Thu Dec 11 17:24:35 2003
+++ bro-pub-0.8a58/configure	Tue Dec 16 15:26:29 2003
@@ -6119,7 +6119,6 @@
 fi
 
     if test "$ac_cv_lib_pcap_pcap_freecode" = no ; then
-	    unset ac_cv_lib_pcap_pcap_freecode
 
 cat >>confdefs.h <<\_ACEOF
 #define DONT_HAVE_LIBPCAP_PCAP_FREECODE
@@ -6154,6 +6153,133 @@
 	    V_INCLS="$V_INCLS -I$pcap_includes"
     fi
 
+		    if test "$ac_cv_lib_pcap_pcap_freecode" = yes ; then
+			CFLAGS="$CFLAGS -I$pcap_includes"
+			echo "$as_me:$LINENO: checking if pcap_compile_nopcap needs error parameter" >&5
+echo $ECHO_N "checking if pcap_compile_nopcap needs error parameter... $ECHO_C" >&6
+			cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+					#include <pcap.h>
+
+int
+main ()
+{
+
+					int snaplen;
+					int linktype;
+					struct bpf_program fp;
+					int optimize;
+					bpf_u_int32 netmask;
+					char str[10];
+					snaplen = 50;
+					linktype = DLT_EN10MB;
+					optimize = 1;
+					netmask = 0L;
+					str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+					(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  result="ok"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+result="wrong"
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+			if test "$result" = "ok" ; then
+				echo "$as_me:$LINENO: result: not needed" >&5
+echo "${ECHO_T}not needed" >&6
+			else
+				cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+						#include <pcap.h>
+
+int
+main ()
+{
+
+						int snaplen;
+						int linktype;
+						struct bpf_program fp;
+						int optimize;
+						bpf_u_int32 netmask;
+						char str[10];
+						char error[1024];
+						snaplen = 50;
+						linktype = DLT_EN10MB;
+						optimize = 1;
+						netmask = 0L;
+						str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+						(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask, &error);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  result="ok"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+result="wrong"
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+				if test "$result" = "ok" ; then
+
+cat >>confdefs.h <<\_ACEOF
+#define LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
+_ACEOF
+
+					echo "$as_me:$LINENO: result: needed" >&5
+echo "${ECHO_T}needed" >&6
+				else
+					{ { echo "$as_me:$LINENO: error: don't know (weird pcap_compile_nopcap)" >&5
+echo "$as_me: error: don't know (weird pcap_compile_nopcap)" >&2;}
+   { (exit 1); exit 1; }; }
+				fi
+			fi
+		fi
+
 
     case "$target_os" in
 
diff -Naur ./bro-pub-0.8a58.orig/lbl-aclocal.m4 bro-pub-0.8a58/lbl-aclocal.m4
--- ./bro-pub-0.8a58.orig/lbl-aclocal.m4	Tue Dec 16 08:55:37 2003
+++ bro-pub-0.8a58/lbl-aclocal.m4	Tue Dec 16 15:26:18 2003
@@ -246,7 +246,6 @@
     dnl check libpcap is modern enough for Bro (>= 0.6.1)
     AC_CHECK_LIB(pcap, pcap_freecode)
     if test "$ac_cv_lib_pcap_pcap_freecode" = no ; then
-	    unset ac_cv_lib_pcap_pcap_freecode
 	    AC_DEFINE([DONT_HAVE_LIBPCAP_PCAP_FREECODE],[],[Old libpcap versions (< 0.6.1) need defining pcap_freecode and pcap_compile_nopcap])
     fi
 
@@ -274,6 +273,58 @@
 	    V_INCLS="$V_INCLS -I$pcap_includes"
     fi
 
+		dnl check if pcap_compile_nopcap needs error parameter (NetBSDism)
+    if test "$ac_cv_lib_pcap_pcap_freecode" = yes ; then
+			CFLAGS="$CFLAGS -I$pcap_includes"
+			AC_MSG_CHECKING(if pcap_compile_nopcap needs error parameter)
+			AC_LINK_IFELSE(
+				[AC_LANG_PROGRAM([[
+					#include <pcap.h>
+					]], [[
+					int snaplen;
+					int linktype;
+					struct bpf_program fp;
+					int optimize;
+					bpf_u_int32 netmask;
+					char str[10];
+					snaplen = 50;
+					linktype = DLT_EN10MB;
+					optimize = 1;
+					netmask = 0L;
+					str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+					(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask);
+					]])],result="ok",result="wrong")
+			if test "$result" = "ok" ; then
+				AC_MSG_RESULT(not needed)
+			else
+				AC_LINK_IFELSE(
+					[AC_LANG_PROGRAM([[
+						#include <pcap.h>
+						]], [[
+						int snaplen;
+						int linktype;
+						struct bpf_program fp;
+						int optimize;
+						bpf_u_int32 netmask;
+						char str[10];
+						char error[1024];
+						snaplen = 50;
+						linktype = DLT_EN10MB;
+						optimize = 1;
+						netmask = 0L;
+						str[0] = 'i'; str[1] = 'p'; str[2] = '\0';
+						(void)pcap_compile_nopcap(snaplen, linktype, &fp, str, optimize, netmask, &error);
+						]])],result="ok",result="wrong")
+				if test "$result" = "ok" ; then
+					AC_DEFINE([LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER],[],
+							[Some libpcap versions use an extra parameter (error) in pcap_compile_nopcap])
+					AC_MSG_RESULT(needed)
+				else
+					AC_MSG_ERROR(don't know (weird pcap_compile_nopcap))
+				fi
+			fi
+		fi
+
 
     case "$target_os" in
 

From sommer at in.tum.de  Wed Dec 17 00:38:20 2003
From: sommer at in.tum.de (Robin Sommer)
Date: Wed, 17 Dec 2003 09:38:20 +0100
Subject: Bro 57 segfaults
In-Reply-To: <200312161712.hBGHCCBZ041896@jaguar.icir.org>
References: <200312161712.hBGHCCBZ041896@jaguar.icir.org>
Message-ID: <20031217083820.GA5691@net.informatik.tu-muenchen.de>


On Tue, Dec 16, 2003 at 09:12 -0800, Vern Paxson wrote:

> I don't run in that environment, but Robin does (or in something similar),
> and I don't believe he's encountered any problems recently.

No, I didn't. But to my experience the tricky part of porting Bro to
different environments is to get it to compile. Crashes encountered
during run-time are usually caused by an OS-independent bug
somewhere in the code.

Robin

-- 
Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Munich    * Phone (089) 289-18006 *  sommer at in.tum.de 


From richard_bejtlich at yahoo.com  Thu Dec 25 05:52:27 2003
From: richard_bejtlich at yahoo.com (Richard Bejtlich)
Date: Thu, 25 Dec 2003 05:52:27 -0800 (PST)
Subject: Error compiling bro-pub-0.8a58
Message-ID: <20031225135227.26149.qmail@web60810.mail.yahoo.com>

Hello,

I'm running

bourque# uname -a
FreeBSD bourque.taosecurity.com 4.9-RELEASE FreeBSD
4.9-RELEASE #0: Mon Oct 27 17:51:09 GMT 2003    
root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC
 i386

I get this error after successfully running
'configure':

...
gcc -g -O2 -I. -I. -g -O0   -c help.c
gcc -g -O2 -I. -I. -g -O0   -c fgetln.c
In file included from fgetln.c:2:
compat.h:4: warning: `__RCSID' redefined
/usr/include/sys/cdefs.h:225: warning: this is the
location of the previous definition
compat.h:5: warning: `__COPYRIGHT' redefined
/usr/include/sys/cdefs.h:247: warning: this is the
location of the previous definition
gcc -g -O2 -I. -I. -g -O0   -c readline.c
gcc -g -O2 -I. -I. -g -O0   -c strlcpy.c
ar -r libedit.a chared.o common.o el.o emacs.o fcns.o
hist.o history.o key.o map.o  parse.o prompt.o read.o
refresh.o search.o sig.o term.o tokenizer.o  tty.o
vi.o help.o fgetln.o readline.o strlcpy.o
bison -y -d -t -v builtin-func.y
flex -obif_lex.cc builtin-func.l
g++ -o bif_lex.o -c bif_lex.cc
g++ -o bif_parse.o -c bif_parse.cc
y.tab.c: In function `int yyparse()':
y.tab.c:1705: syntax error before `goto'
*** Error code 1

Stop in /usr/local/src/bro-pub-0.8a58.

--

I appreciate any help.

Thank you,

Richard Bejtlich
http://www.taosecurity.com

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


From vern at icir.org  Mon Dec 29 23:51:37 2003
From: vern at icir.org (Vern Paxson)
Date: Mon, 29 Dec 2003 23:51:37 -0800
Subject: Error compiling bro-pub-0.8a58
In-Reply-To: Your message of Thu, 25 Dec 2003 05:52:27 PST.
Message-ID: <200312300751.hBU7pbBZ098332@jaguar.icir.org>

> g++ -o bif_parse.o -c bif_parse.cc
> y.tab.c: In function `int yyparse()':
> y.tab.c:1705: syntax error before `goto'

y.tab.c is a generated file, so to diagnose it, please send a copy
of it, and/or lines 1700-1710 in order to localize the error.

		Vern