[Bro-Dev] Call for opinions on logging framework syntax problem

Gregor Maier gregor at icir.org
Tue Nov 29 19:04:00 PST 2011

I'm wondering whether we should maybe start including the protocol in 
the same column in the log files. I.e., the column would then be 

Or we could handle ports similar to embedded records in the log file. 
I.e., if we log a port variable named "orig_p" we would get two columns:
   orig_p.port orig_p.proto
I actually like this variant!


On 11/29/11 16:53 , Bernhard Amann wrote:
> Hello,
> I am currently working on the input framework for bro -- which allows reading previously written log files back into bro -- and have encountered a little problem when reading port fields. There are several different methods to solve this problem and I wanted to get a little bit of feedback before implementing any of these solutions.
> First to describe the problem...
> When the logging framework is used to log port information, the information does not include the protocol -- this is usually stored in a second column.
> Hence, a logfile storing port information will usually look something like this
> #fields host_a host_p proto
> 80 tcp
> The input framework uses record types to define, what fields should be read from a previously written logfile.
> To read the fields, one could e.g. define a record like this:
> type Values: record {
> 	host_a: addr;
> 	host_p: port;
> }
> The problem with this approach is, that now host_p does not contain the protocol of the port, because it is stored in a different, unrelated column.
> Hence, the input framework needs a (preferably syntactically nice, easy to understand) way to identify the column that is used to store the port information.
> The easiest solution would be just to assume a fixed column name (e.g. host_p_port if the port is stored in host_p), but this is probably not a very good idea for a number of reasons.
> The nicest way we could think of at the moment is to use annotations for this; for our example one could e.g. use
> type Values: record {
> 	host_a: addr;
> 	host_p: port&protocol_column=proto;
> }
> This has the disadvantage of introducing a new, very specialized annotation that is only used for this one case.
> Does anyone else have any ideas / suggestions?
> Bernhard
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro-ids.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Gregor Maier
<gregor at icir.org>  <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA

More information about the bro-dev mailing list