Need help! Link failed during compile 0.8a34 version

Hi,

I am new here.
I tried to get whole archive from majordomo for previous mailing messages and looks like I am still waiting.

I was trying to compile the package under redhat 9.0.

I got the following error message in last link sentence.
I still got the same error even after I upgraded the bind to latest redhat update (glibc-2.3.2-27.9).

nb_dns.o(.text+0x62d): In function `nb_dns_activity':
: undefined reference to `__ns_initparse'
nb_dns.o(.text+0x6f2): In function `nb_dns_activity':
: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x6f8): In function `nb_dns_activity':
: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x870): In function `nb_dns_activity':
: undefined reference to `__ns_parserr'
collect2: ld returned 1

Could anyone help me? Thanks!

Hongjie

Please try the attached patch. It works at least for Debian-based
systems.

Robin

P.S.: If anyone happens to know enough about autoconf to include
this into configure.ac, it would be a nice thing to add.

bro-cvs-libresolv.diff (553 Bytes)

Appreciate. It works.

Meanwhile I searched something from google newsgroup.
It may explain the reason.

# nm /usr/lib/libresolv.a | sed "s/[^ ]* //" |sort > a
# nm /usr/lib/libresolv.so | sed "s/[^ ]* //" |sort > so
# diff a so |grep __ns_initparse
  < T __ns_initparse
  > t __ns_initparse
  < U __ns_initparse

From 'info nm', lowercase t means local, uppercase T means global

That's different among libresolv.a and libresolv.so.

No idea why glibc leaves such arrangement.

Hongjie

Robin Sommer wrote:

Hi all,

> I was trying to compile the package under redhat 9.0.

Please try the attached patch. It works at least for Debian-based
systems.

here's an attempt of a configure check for this; it works for my RH9.
Open questions:

- what to do if workaround test fails
- whether to test for other locations of libresolv.a

Let me know if it works for you -- I'm far from an autoconf expert. In
particular, I don't know if it'll work with other autoconf versions
(that's always where the fun starts ...).

Cheers,
Christian.

bro-ns.diff (863 Bytes)

Works fine on Debian, too (and also on Solaris and FreeBSD which
don't need the work-around).

Thanks!

Robin

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. 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

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

Robin

bro-0.8a34-icmpfix.diff (1.41 KB)

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

Hmm, what does it actually do?

>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

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

Below is a newer version of Robin's patch.

[anton@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,

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

Ruoming

icmp-fix.diff (2.44 KB)

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,