[Bro-Dev] Autodoc: how to link to another script?

Seth Hall seth at icir.org
Wed Aug 10 12:31:16 PDT 2011

On Aug 10, 2011, at 2:41 PM, Gregor Maier wrote:

> The connection record type has an optional field tunnel_parent. I actually added that in bro.init, since I forgot that we can now extend records with +=.

Haha, get that out of there! :P

>    type parent_t: record {

You may want to check out: http://www.bro-ids.org/development/script-conventions.html

It certainly makes the code easier to read if everyone names things consistently.

> I could actually add this tunnel_parent field in my tunnel.bro script that logs child-conn-id <--> parent_t

I'm actually starting to wonder if tunnel.bro should go in base/protocols/conn/.  That actually seems like the appropriate place since it has to do with connections.  It's just using extra core support to find and log these tunnels.  I would still extend the Conn::Info type in the tunnels.bro script though.  What do you think?

> However, today I thought it might be handy to at least add the tunneltype to conn.log as and indicator whether a particular connection was tunneled or not. That's why I added a "tunnel_type" field to the Conn::Info record (in conn.bro).
> So, while I directly modified the conn/main.bro script, it doesn't depend on the code in the framework part. Not sure what you mean by
> "depend" though.

Nevermind.  I was sort of still thinking along the lines of a tunnel framework or something.  I just don't want to see frameworks @load-ing anything out of protocols/.  If integration needs to happen I think it should happen the other way (the protocol loading the framework and pulling data from it or something).  It irrelevant if you put the tunnels.bro file in base/protocols/conn/.

> However, if multiple scripts to this, then the order of columns in conn.log would depend on the order in which these scripts are loaded..... Thinking of this some more, I think that the http-scripts already do this, so the order of columns isn't well-defined anyways, right? And if somebody writes a script to parse a bro log file, then one has to check the header, right?

You've got it.  I'm hoping to get everyone away from the notion of column numbers even.  Once we get binary logging added it will really be inconsequential because you will essentially load a log (or logs) and request specifically named fields from the log since the binary log doesn't have a notion of column ordering anyway.  For the ascii logs, looking at the headers certainly works though.  In most cases if people just use the default loaded scripts as-is we should maintain pretty steady column ordering for most columns.

If you can tell, I'm tired of file format parsing ever getting in the way of doing actual analysis. :)


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list