Hi Everyone,
I’m create a new analyzer for Bro and am currently just trying to create a skeleton that does nothing, but compiles. I’m currently stuck at a compile error that I don’t really know the meaning of “cannot handle incremental input”
I basically copied another analyzer and stripped out everything but the basics. The only reference I could find to incremental input on the wiki was using flowunit versus datagram in the *-analyzer.pac file. But I am using flowunit there.
Any help would be much appreciated,
Kristin
Could you send along your .pac files? It usually has to do with a unit where you are trying to have a bytestring parsed until &endofdata, but the unit or the parent unit doesn't have a &length applied (I think).
.Seth
Attached are my .pac files. There’s close to nothing in them though. I don’t use &endofdata anywhere.
Kristin
bgp.pac (216 Bytes)
bgp-analyzer.pac (255 Bytes)
bgp-protocol.pac (215 Bytes)
You are naming a field "length" in bgp-protocol.pac. That token name is used for the unit length so you are essentially saying that your entire BGP_Message unit is the size of that &length field.
Just change the name. 
.Seth
Oops, nevermind. My answer just a second ago is wrong. I'll look around a bit more.
.Seth
I think you found a bug in binpac. I've noticed that bytestrings aren't handled correctly everywhere as you would expect if they have a static length (as it seems to be happening here).
In bgp-protocol.bro, if you change...
marker: bytestring &length=16;
to
marker: uint8[16];
that will fix a piece of the problem, but you also need to define the total length of your outer containing unit (BGP_Message). The following code will do it.
type BGP_Message = record {
marker: uint8[16];
length: uint16;
type: uint8;
msg: bytestring &restofdata;
} &byteorder = bigendian &length=length;
With that change to the BGP_Message, it compiles fine for me. Looking forward to a BGP analyzer!
.Seth
Just for the sake of my own understanding. The changes you made above
say the exact same thing I had originally except they don't use the
&length attribute. And normally it would work except there is a bug
with bytestring and setting its &length property?
Kristin
Just for the sake of my own understanding. The changes you made above
say the exact same thing I had originally except they don't use the
&length attribute.
Sort of. When you go to use the marker value you will be receiving an array of 8bit ints instead of a bytestring value, but you can just write you code around that (assuming you are even using the marker value). The main thing is that I set a length on the whole record.
And normally it would work except there is a bug
with bytestring and setting its &length property?
The bug is only prevalent in certain cases because binpac has to know the full size of the unit before it hits a dynamically sized field (if I understand it correctly) but for some reason even if you set a static size for a bytestring it thinks that's a dynamically sized field still which is why I changed it to a 16-long uint8 array.
Seth