I'm trying to collect event_notice and event_alarm events from a
bro 1.4 instance via broccoli and seeing some odd behavior, and was
wondering if its something others have seen (and figured out).
What happens is the client connects, and requests those events,
and the server logs the connection and the request for events.
Everything looks fine, except that nothing comes through, and the bro
child/communicatons process starts to bloat up rapidly. Eventually the
process becomes huge and seg faults, leaving the parent bro processing
humming along happily. The entire time, not a single event arrives at
the client.
It almost looks as if the events are sent over to the child
process where they queue up for delivery, yet nothing goes through. I
saw that there is the suppress_notice_action flag which is set to F,
but the description sounds like it suppressed events arriving from a
remotero.
I am able to use the same client, and collect connection_finished
events, with no sign of the bro child process bloating up and dying,
so it seems to be something related to the event_notice and
event_alarm events. The NoticeAction and notice_info types passed for
those events are more complex than the connection_finished params,
would the optional fields and enumerated types in NoticeAction and
notice_info cause problems for marshalling and sending?
Thanks for the feedback. Could you provide a bit more detail about the
setup? In particular, what codebase are you using, and what are the
connection flags on the Broccoli side?
I'm trying to collect event_notice and event_alarm events from a
(I suppose you mean notice_action and notice_alarm?)
humming along happily. The entire time, not a single event arrives at
the client.
That's weird. I don't have an immediate idea why you see that; the
cluster is sending notice_action events and that's working fine.
saw that there is the suppress_notice_action flag which is set to F,
Right, that option shouldn't have any impact on this
would the optional fields and enumerated types in NoticeAction and
notice_info cause problems for marshalling and sending?
They shouldn't. Generally, all script-level variables can be
transmitted. If not it's a bug ... :
There are two things which could help tracking this down: if you
could find like a minimal configuration/setup which demonstrates the
problem, that'd be great (always a bit tricky when communication is
involved...). And you could compile with --enable-debug and then run
with "-B comm", that will log some stuff into debug.log which might
help (that file quickly gets huge though).
Christian,
We're using Bro 1.4 on both client and server sides. Our 1.4
source tree looks like it was generated on March 18, 2009, so I would
expect that it was current as of that date (Scott can confirm).
Here's the code for acquiring the connection handle:
if (! (bc = bro_conn_new((struct in_addr*) host->h_addr_list[0],
htons(conf.port),
BRO_CFLAG_DONTCACHE))) {
fprintf(stderr,"Could not obtain connection handle to %s:%d\n",
conf.hostname, conf.port);
exit(1);
}
So the only flag is the BRO_CFLAG_DONTCACHE
I'm using the compact argument style handler, and converting the
incoming parameters into perl variables and handing them off to a perl
function for processing. I don't think the c->perl interface is an
issue because the client never seems to receive the events.
I'm trying to collect event_notice and event_alarm events from a
(I suppose you mean notice_action and notice_alarm?)
Yes, that's what I meant to write, even if I didn't!
There are two things which could help tracking this down: if you
could find like a minimal configuration/setup which demonstrates
the problem, that'd be great (always a bit tricky when
communication is involved...). And you could compile with
--enable-debug and then run with "-B comm", that will log some
stuff into debug.log which might help (that file quickly gets huge
though).
I will try to get this today. I expected that the notice_action
stuff was being used for the bro cluster, so I'm thinking it is just
something dumb and/or obvious that I'm missing.
Actually, I'm realizing that I mentally skipped the "Broccoli" part
of your original mail; I had a pure Bro-to-Bro setting in mind when
I replied, and that's what the cluster is using (the cluster doesn't
use Broccoli for sending the notice_* events). So, if the problem
would be on the Broccoli side, that could explain why we haven't
seen it so far.
