I'll just try to answer to your comments in the sequence they came
> $ ./bro ~/devel/Broccoli/test/broping.bro
> 1117837283.819435 warning: event handlers never invoked:
> 1117837283.819435 warning: ping
> $ broping
> pong event from 127.0.0.1: seq=0, time=0.010662/1.010452 s
> pong event from 127.0.0.1: seq=1, time=0.008867/1.008964 s
> pong event from 127.0.0.1: seq=2, time=0.038239/1.009833 s
> pong event from 127.0.0.1: seq=3, time=0.009923/1.009428 s
> pong event from 127.0.0.1: seq=4, time=0.038738/1.009980 s
I stopped bro and used nmap to scan 47757 and 47758 and they are both
closed. I then restarted bro with load @broping as the last line in my
local.site.bro and repeated the scan with the result that 47757 is now open.
Sounds good. To be extra sure that no policy settings interfere with
broping.bro, just run broping.bro directly as shown above.
The latest iana.org list shows these ports are in an 'unassigned' range. I
am starting bro logged in a root and the bro.cfg file defines root as the
Don't be root -- there's no need. The reason why we're using the high
ports in the unassigned range is precisely so you don't have to be root.
The comm.log file says that bro is listening on 127.0.0.1:47757. It also
complains on the line above this that "can't bind to port: address in use".
I have no clue what this means, since the port scan shows those ports closed
when bro is stopped.
I'm guessing that multiple attempts were made to bind to that port, and
while the first one didn't succeed the following one did. Looking at the
code I think that when Bro says it's listening, it definitely is.
I looked at broping.bro, which loads listen-clear.bro which loads
remote.bro. remote.bro defines 'default_port_clear=47757.tcp'.
listen-clear.bro uses this value to initialize listen_port_clear.
broping.bro checks to see if listen_port_clear is defined and if so
redefines it to 47758. If this were successful, would not the port scan show
47758 as open? Running broping -d -d I see in the output that the connection
was refused to 127.0.0.1:47758.
Does it say "connection refused", or "Could not connect to Bro"? This
difference is important -- the former would mean the TCP connection
couldn't be established, while the latter would mean something in the
Bro-internal protocol handshake may have gone wrong.
Make sure your high ports aren't firewalled.
Here's another bit: when I broping -p 47757, the comm.log shows 'request for
unknown event pong' errors. It acts like broping.bro is not getting loaded.
So now the connection definitely gets established; I'll assume the
connection refused problem above was a "Could not connect to Bro".
Just avoid any doubts regarding whether or not broping.bro is loaded
correctly by running Bro directly with it, per my example.
Is bro prone to fail things silently?
Not in general, no.
I have tried a few more things. It appears to me that my local.site.bro is
not getting called. I can use broping.bro or broping-record.bro as my
starting policy in bro.cfg and I can verify that bro is listening on 47758
with nmap. I can capture the transactions with tcpdump per Scott's
recommendation and I can see that there are 7 messages from 127.0.0.1:34102
to 127.0.0.1:47758 with replies.
That all sounds good.
I forget how to interpret the payloads, but
I'll go back and read the manual.
Don't bother, that's just the details of the serialization protocol.
In any event, all the combinations of
broping.bro, broping-record.bro and broping -r return "Could not connect to
bro at 127.0.0.1:47758".
Okay. Note that this is a Broccoli-level error message and not at TCP
one (I'll make sure that error message is more clear in that regard for
0.8). The underlying TCP connection does work, according to your
description above. Debugging output will likely allow me to answer
what's going on.
So, I reconfigured bro with bro_config. It sets the start policy to
localhost.localdomain.bro and I gave it an empty file. I'm not sure I'm
entirely clear as to the purpose of this parameter, but that's OK--I don't
think that's where the problem lies. With this configuration, the broping
script is not getting called and it looks to me that local.site.bro is not
getting called. I put print and log statements in it and I don't see
anything on standard out or in the logs.
So, does local.site.bro get called automatically or do I have to coerce it
with a load statement? If I can make sure bro is configured properly then
maybe the rest will fall into place. I notice that bro_config writes some
network information into local.site.bro. What happens to bro if this
information is not available?
Forget all this for now -- just run broping.bro directly. Once that
works, we can always add more stuff around it.