Understanding the event generation and handling

Hi,

I've been looking at the Bro documentation and source code recently. I need to get into lower-level details and looking at Source code is not helping me.

Specifically, I need to get to the logic of-
1. Event generation: How does Bro know which all events to raise by looking at a particular packet? I have a basic understanding of the class hierarchy, but I don't know where to look for the code that decides which specific Application layer analyzer object to create by looking at the Application Layer header/signature of the incoming packet.

2. Event handling: It seems that an event's information is stored in an object and all events are queued in an Event Manager as they are created. After every packet is processed, this queue of events is drained (thus following a single-threaded model) and the events are sent to a Serializer. I found the serialization code hard to understand so I don't know the logic of how an event-handler (interpreter?) decides which event belongs to it. I'd really like to know the mechanism in here.

Can someone please suggest which debugger to use and how, so that I can step-by-step understand the event-engine?

Thank you,
Sunjeet Singh

Specifically, I need to get to the logic of-
1. Event generation: How does Bro know which all events to raise by
looking at a particular packet?

There is a tree of analyzers that's traversed (perhaps taking multiple
branches at any given point).

I have a basic understanding of the
class hierarchy, but I don't know where to look for the code that
decides which specific Application layer analyzer object to create by
looking at the Application Layer header/signature of the incoming packet.

The architecture here is described in the paper:

  http://www.icir.org/robin/papers/usenix06.pdf

If you are looking for specific details regarding names of classes/methods,
etc., then you'll probably have to wait until Robin comes back from vacation
in a couple of weeks.

2. Event handling: It seems that an event's information is stored in an
object and all events are queued in an Event Manager as they are
created.

Correct.

After every packet is processed, this queue of events is
drained (thus following a single-threaded model) and the events are sent
to a Serializer. I found the serialization code hard to understand so I

Ignore the serializer. It's there for things like communication between
multiple Bro processes.

Can someone please suggest which debugger to use and how, so that I can
step-by-step understand the event-engine?

Well, I use gdb, and if I must, I start with invocations of
NetSessions::NextPacket .

If you want to sketch your particular goal, that might help with giving
you more focussed advice.

    Vern

Hi Vern,

The architecture here is described in the paper:

  http://www.icir.org/robin/papers/usenix06.pdf

Thanks! I'll take a look.

Well, I use gdb, and if I must, I start with invocations of
NetSessions::NextPacket .

This is helpful.

If you want to sketch your particular goal, that might help with giving
you more focussed advice.

I'm interested in Bro in general, but right now I'd be interested to know details about how event handling was implemented in Bro.
So for every event from the event queue, how many handlers is it matched against for the right handlers to be invoked? All?(Probably not)
Could you please shed some light on the details here? Do you think there could be scope for optimization?

Thank you,
Sunjeet Singh

So for every event from the event queue, how many handlers is it matched
against for the right handlers to be invoked?

There's no matching at all. Rather, when policy scripts define new event
handlers, they're directly associated with the name of the event. So when
the event engine generates event_XXX, there's already (scripting) code
associated with a global variable named event_XXX, and that's executed
directly.

Do you think there
could be scope for optimization?

No. Where optimization would prove fruitful (but hard) is for the script
interpreter.

    Vern