FYI, the pre-test has been updated to:
http://www.icir.org/vern/tmp/bro-1.2.18.tar.gz
with the main changes being fixes for ICMP messages that include non-TCP/UDP
excerpts, and a BinPAC portability tweak.
Vern
FYI, the pre-test has been updated to:
http://www.icir.org/vern/tmp/bro-1.2.18.tar.gz
with the main changes being fixes for ICMP messages that include non-TCP/UDP
excerpts, and a BinPAC portability tweak.
Vern
Fyi, the latest 1.3 pre-release is now available at:
http://www.icir.org/christian/bro/bro-1.2.19.tar.gz
This one has additional gcc 4.x compatibility fixes and should also no
longer cause the regex parser errors some people saw earlier:
http://www.bro-ids.org/wiki/index.php/"Error_compiling_pattern"
Cheers,
Christian
Hello,
I tested the previous testing release on OpenBSD and the compile stage
worked well.
Very good job !!
I've (too) some remarks :
1°) There was a little problem with "bro.rc" which didn't want to run
because we use a function called "stop()", i suggest to call it
"brostop()" in order to evade some problems with the shell
2°) I worked on the (in)famous "DNS non blocking" section,
if we add the "libbind" package (using 'pkg_add libbind'), we should
have the non blocking features.
So i tried but i think there's a typo's problem inside "configure.in"
I've (too) some remarks :
We've attempted to incorporate these into
http://www.icir.org/vern/tmp/bro-1.2.20.tar.gz
Please let us know if any of hte problems remain.
Vern
Hi,
As mentioned later from Jean-Philippe it runs fine on OpenBSD-i386.
I'm got allways core dumps when I run it on SPARC64 machines on
Solaris 8 and on OpenBSD 4.1-current could this an endian problem?
gdb example (OpenBSD; bro 1.2.19):
Hello all,
It's not related to OpenBSD (same thing on a Debian) but i run into a problem with
policy/tftp.bro :
/opt/share/bro-1.3/policy/tftp.bro, line 59: error: unknown identifier
uncomment, at or near "uncomment"
I think the various ";;;;" are the problem, i had to replace them with "#".
+-+-+ tftp.bro
;;;; uncomment the following
### global sessions: table[conn_id] of tftp_session_info;
### # The following yields a conn_id that should be present in "sessions".
### global sessions_index: table[tftp_session_id] of conn_id;
### global session_id = 0;
/opt/share/bro-1.3/policy/tftp.bro, line 59: error: unknown identifier
uncomment, at or near "uncomment"I think the various ";;;;" are the problem, i had to replace them with "#".
Oops - that came from building the distribution in a tree that inadvertantly
included a new, not yet completed TFTP analyzer - sorry about that.
Vern
Hi Stephan,
Hi,
As mentioned later from Jean-Philippe it runs fine on OpenBSD-i386.
Cool, I'm glad that's sorted out.
I'm got allways core dumps when I run it on SPARC64 machines on
Solaris 8 and on OpenBSD 4.1-current could this an endian problem?gdb example (OpenBSD; bro 1.2.19):
----
Program received signal SIGBUS, Bus error.
Connection (this=0x0, s=0x12207c8, k=0x1222208, t=1165532761.666986,
id=0xffffffffffff7350) at Obj.h:123
123 location = 0;
(gdb)
----
Ouch, that looks pretty serious. Could you post or send me a backtrace
when that crash occurs? (Just type "bt" at the gdb prompt.) Also, how
are you running Bro when this happens (on a particular trace, live
traffic, etc.)?
Thanks very much for your feedback.
Cheers,
Christian
Hi Christian
I've compiled bro 1.2.20 an run the test again with the same
bus error. At the moment I'm using a pcap file to run the
test.
Here are the gdb output:
$ sudo gdb bin/bro
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.1"...
(gdb) run -r /home/pcap/test.pcap mt
Starting program: /usr/local/bro/bin/bro -r /home/pcap/test.pcap mt
Program received signal SIGBUS, Bus error.
Connection (this=0x0, s=0x12955d8, k=0x1297318, t=1165532761.666986,
id=0xfffffffffffdd0d0) at Obj.h:123
123 location = 0;
(gdb) bt
#0 Connection (this=0x0, s=0x12955d8, k=0x1297318, t=1165532761.666986,
id=0xfffffffffffdd0d0) at Obj.h:123
#1 0x0000000000262708 in NetSessions::NewConn(HashKey*, double, ConnID const*, unsigned char const*, int) (this=0x12955d8, k=0x1297318, t=1165532761.666986,
id=0xfffffffffffdd0d0, data=0x1290ee4 "\215¼", proto=19495908)
at Conn.h:304
#2 0x000000000014a6a4 in ConnCompressor::Instantiate(double, HashKey*, IP_Hdr const*) (this=0x1288380, t=1165532761.666986, key=0x1297318,
ip=0xfffffffffffdd3c0) at IP.h:115
#3 0x00000000001495f4 in ConnCompressor::NextPacket(double, HashKey*, IP_Hdr const*, pcap_pkthdr const*, unsigned char const*) (this=0x1288380,
t=1165532761.666986, key=0x1297318, ip=0xfffffffffffdd3c0, hdr=0x128c9e0,
pkt=0x1290ec2 "") at ConnCompressor.cc:171
#4 0x000000000025f7d4 in NetSessions::DoNextPacket(double, pcap_pkthdr const*, IP_Hdr const*, unsigned char const*, int) (this=0x12955d8,
t=1165532761.666986, hdr=0x128c9e0, ip_hdr=0xfffffffffffdd3c0,
pkt=0x1290ec2 "", hdr_size=14) at Sessions.cc:544
#5 0x000000000025f278 in NetSessions::NextPacket(double, pcap_pkthdr const*, unsigned char const*, int, PacketSortElement*) (this=0x12955d8,
t=1165532761.666986, hdr=0x128c9e0, pkt=0x1290ec2 "", hdr_size=14,
pkt_elem=0x0) at Sessions.cc:294
#6 0x0000000000212f80 in net_packet_dispatch(double, pcap_pkthdr const*, unsigned char const*, int, PktSrc*, PacketSortElement*) (t=1165532761.666986,
---Type <return> to continue, or q <return> to quit---
hdr=0x128c9e0, pkt=0x1290ec2 "", hdr_size=14, src_ps=0x128c9a0,
pkt_elem=0x0) at Net.cc:402
#7 0x0000000000226a98 in PktSrc::Process() (this=0x128c9a0) at PktSrc.cc:216
#8 0x00000000002132c8 in net_run() () at Net.cc:491
#9 0x0000000000109b88 in main (argc=1024, argv=0x400) at main.cc:1009
(gdb)
Best regards,
Stephan
Connection (this=0x0, s=0x12955d8, k=0x1297318, t=1165532761.666986,
id=0xfffffffffffdd0d0) at Obj.h:123
123 location = 0;
Any chance you're running out of memory? It's failing inside a routine
"new" allocation.
Depending on your shell, you might try raising your per-process memory
limits. In tcsh, for example, via "unlimit datasize".
Vern
Hi list, I'm having a problem compiling 1.2.20. Looking for any advice.
Compiling on Ubuntu Feisty
include -O -W -Wall -Wno-unused -I../linux-include -g -O2 -c -o FTP.o `test -f 'FTP.cc' || echo './'`FTP.cc
source='File.cc' object='File.o' libtool=no \
depfile='.deps/File.Po' tmpdepfile='.deps/File.TPo' \
depmode=gcc3 /bin/bash ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../aux/binpac/lib -I../src -I. -I.. -Ilibedit -I../linux-include -O -W -Wall -Wno-unused -I../linux-include -g -O2 -c -o File.o `test -f 'File.cc' || echo './'`File.cc
File.cc: In member function ‘void BroFile::InitEncrypt(const char*)’:
File.cc:666: warning: dereferencing type-punned pointer will break strict-aliasing rules
source='FileAnalyzer.cc' object='FileAnalyzer.o' libtool=no \
depfile='.deps/FileAnalyzer.Po' tmpdepfile='.deps/FileAnalyzer.TPo' \
depmode=gcc3 /bin/bash ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../aux/binpac/lib -I../src -I. -I.. -Ilibedit -I../linux-include -O -W -Wall -Wno-unused -I../linux-include -g -O2 -c -o FileAnalyzer.o `test -f 'FileAnalyzer.cc' || echo './'`FileAnalyzer.cc
FileAnalyzer.cc: In member function ‘void File_Analyzer::Identify()’:
FileAnalyzer.cc:80: error: ‘cl_scanbuff’ was not declared in this scope
FileAnalyzer.cc: In static member function ‘static void File_Analyzer::InitClamAV()’:
FileAnalyzer.cc:113: error: ‘cl_loaddbdir’ was not declared in this scope
make[3]: *** [FileAnalyzer.o] Error 1
make[3]: Leaving directory `/home/tarupp/bro-1.2.20/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/tarupp/bro-1.2.20/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tarupp/bro-1.2.20'
make: *** [all] Error 2
clamav-dev version is 0.90.2-0ubuntu1
Thanks in advance.
-Tim
Vern Paxson wrote:
Hi Stephan,
Hi Christian
I've compiled bro 1.2.20 an run the test again with the same
bus error. At the moment I'm using a pcap file to run the
test.
Thanks. I'd like to try to reproduce the error, but I can't seem to get
a build on the sole Solaris box I have access to, which is a
"SunOS 5.9 Generic_122300-06 sun4u sparc SUNW,Sun-Fire-880 Solaris".
I see two gccs on that box, 3.4.2 and 4.1.2. With both, I get clashes
between C header files and STL types, à la
/usr/include/net/if.h:87: error: template argument required for `struct map'
With gcc4, I also had to add -lstdc++ to LDFLAGS. Are there any
additional Solaris tricks one has to apply to work around these
problems, or did the build Just Work for you? What compiler are you
using?
Cheers,
Christian
Hi list, I'm having a problem compiling 1.2.20. Looking for any advice.
Hi Tim,
From your report it looks like there is more variance in the ClamAV API
than we were aware of. Unfortunately we don't currently provide
--disable-clamav at configure time. If you don't really need ClamAV
functionality, the kludge to try would be removing clamav-dev, so Bro
won't pick it up. We'll make sure this becomes more configurable in the
future...
Cheers,
Christian
Christian Kreibich wrote:
Hi Christian,
At the moment I'm testing only on a Sun SPARC64 with
OpenBSD 4.1.
Next week I can compile bro on a Solaris 8 with gcc 4.1.2.
As I'm compiled bro 1.1. last time Solaris 8 I've had no
compile errors as I remember.
Best regards,
Stephan
Hi Christian
Had the same problem with Solaris 8 and gcc 4.1.2. Solved this by
commenting out the #include: