I have begun testing the cross-bro communication functionality, and have a few problems. Are there any example configurations that I might look at? Currently I have boxes acknowledging one another, but am having difficulty getting events to move across.
Does anybody have any sort of documentation or examples? Anything would be helpful at this point...
Many thanks!
scott
I'm sure Robin will have all the definitive answers for you but I can
point out one caveat when it comes to testing the comms stuff that might
sound a bit funny: make sure Bro is busy. I believe the current event
loop needs to see packets on the monitored interfaces to keep the loop
going (and thus allow event I/O to be processed). If somebody could
acknowledge or disprove that this is the case that would be most
helpful!
Documentation is still scarce but if you have the Bros acking each other
you should basically be set.
The latest Broccoli release contains a "broping" test tool that will
send a "ping" event to a Bro, and with broping.bro policy (included in
the tarball) running on the remote Bro you should get to see "pong"
events coming back:
cpk25@localhost:/home/cpk25/devel/broccoli > ./test/broping
pong event from 127.0.0.1: seq=1, time=0.004700/1.010303 s
pong event from 127.0.0.1: seq=2, time=0.053777/1.010266 s
pong event from 127.0.0.1: seq=3, time=0.006435/1.010284 s
pong event from 127.0.0.1: seq=4, time=0.020278/1.010319 s
pong event from 127.0.0.1: seq=5, time=0.004563/1.010187 s
pong event from 127.0.0.1: seq=6, time=0.005685/1.010393 s
You can snarf a copy at http://www.cl.cam.ac.uk/~cpk25/vern .
Good luck,
Christian.
Do you already have a copy of the independent-state paper? (If not,
I may send a you one). It describes the basic mechanisms, and shows
a few lines of code. Unfortunately, that's all the documentation
that exists currently.
Quick example: One Bro loads listen-clear.bro which opens a port for
incoming connections. A second Bro gets
@load remote
redef remote_peers_clear += {
[127.0.0.1, 47756/tcp] = [$events = /.*/, $retry = 60 secs]
};
Upon startup, it will connect and request all events matching the
regxp '.*'.
Christian is right that some network activity is needed - at least
if Bro listens on some port *and* one some capture interface
simultaniously (Christian is working on some nicer select()-based
event loop which should avoid these kinds of problems. Thanks!). If
you don't give a capture interface to the receiving Bro, it *should*
work w/o any network traffic (obviously, as there is none). In fact,
it used to do that (I used that for quite some time), but, as I've
just seen, it doesn't anymore. I'll have to look into the code to
see what goes wrong.
Note that the communication interface is going to change quite soon
(I'm now cleaning-up the serialization; communication will be next
and it will affect the script-level interface). So, before relying
on the communication, it could be worth waiting a bit more.
Robin