I am creating an application based on the broccoli test/broconn source. It seems when running the broconn example and the application I am writing using bro versions 2.0 and 2.1, I can subscribe to “new_connection” events and process them in a callback; everything is great. But when using bro version 2.3 there is no processing of the events sending them to the callback. This goes for the broconn example and my app.
The ping example does work for version 2.3 which is using custom events.
I can capture the client server traffic and see the ‘new_connection’ events being passed back to the client but the client side code seems to not do anything for bro v2.3, this goes for my app and the broconn example.
I was not able to try bro v2.2, when executing bro it would display a bunch of warnings for magic files and the following message, then quit
“internal error: can’t load magic file /usr/local/bro/share/bro/magic: could not find any valid magic files!”
This is being on fedora 20 and arch linux, tried all versions of bro (v2.0,2.1,2.2,2.3) using the src tarballs and the git repo.
The “connection” record in Bro has evolved over time to include data types that Broccoli clients can no longer process (I think it’s “opaque” types that are now problematic, but may be misremembering). Broccoli silently (unless debug output is turned out) fails to invoke callbacks for events that use those data types.
As a general suggestion, try writing custom Bro events to pick and choose particular things to send to Broccoli clients. E.g.:
global my_custom_new_connection: event(cid: conn_id);
event new_connection(c: connection)
Then have the Broccoli client register a callback for “my_custom_new_connection” instead of “new_connection”.
I think this should workaround the bug in Broccoli as well as be more efficient (unless the Broccoli client actually intended to make use of every last bit of data in the connection record). Also, the new library being developed to replace Broccoli/Bro communication, called Broker, is planned to require being explicit about the content of remotely communicated messages. So writing code in this way should make it easier to adapt to the new library when available.
Thank you, I will go that path with my development.