Are notice tags used by anyone? They are the values that looks like this: "39-4b24-1" in the notice.log file. I'm not sure what the impetus for creating those was but they look to be a combination of timestamp derived value, process id, and incrementing counter.
I've never had a use for them and wondered if it's worthwhile keeping them around.
.Seth
Are notice tags used by anyone?
They are handy for grepping. The tag also appears in the conn file
(as an $addl element), so you can link the two together.
Vern
(... and the values don't have any further semantics, they are just
supposed to be unique, pretty much like the new conn uids but per
notice rather than per connection).
Robin
Heh, it actually doesn't right now. 
I'll add that back in (notice id in conn.log), I can see it being useful in some cases. With the record extension stuff, I think I'll be implementing it as a separate field just for notices and it will probably be implemented in the notice script itself. I never liked that $addl field, it was always hard to figure out what it was for.
Should there be a separate and built in way to generate unique ids? What bothered me about the tag implementation in the notice script is that it's a bit difficult to figure what's going on due to dealing with non-determinism of the tags because of the data it bases the tags on. If we had a BiF that just generated unique IDs, we could build all of the determinism in there and wouldn't have to worry about it anymore where we need unique IDs.
Thanks,
.Seth
Should there be a separate and built in way to generate unique ids?
Nice thought.
Vern
If we had a random() BiF I think we could do it pretty easily in scripting land because we could just fmt() the output from the random() function and trim it to a certain length. That gets us the on-demand determinism for testing and it's reusable for other things (if we ever need a random number generator again).
.Seth
If we had a random() BiF I think we could do it pretty easily in scripting land because we could just fmt() the output from the random() function and trim it to a certain length.
I'm not sure that's as good. We either need long tags, or have to start
worrying about collisions. (Though if we had formatting to something like
radix-64, then we could probably get both short tags and almost no chance
of collision.)
That gets us the on-demand determinism for testing and it's reusable for
other things (if we ever need a random number generator again).
I think random() in general makes sense, just not sure this should be one
of its applications.
Vern
The random() data would only be used for a notice prefix. I think we'd only generate the random ID at init time and then use an incrementing counter as a postfix for the full ID of each notice after that which is how it's done now. The only chance we'd have for collisions would be in a cluster context between nodes generating notices. Each node would never generate a conflict unless it managed to overflow a 64-bit int.
.Seth
What about synchronizing a seed across the bro cluster, and using that seed to generate random() concatenated with 48 bits obtained from the machine (adapter Ethernet address?) to ensure the starting value was unique across the whole cluster?
--Gilbert
We could use the node name somewhere to help create uniqueness. MAC address wouldn't actually work because in many cases, people are only sniffing a single interface with a MAC address for their entire cluster.
.Seth
Didn't we just solve this problem for the conn uids? It even does
radix-64. We could reuse some of that code to generate unique IDs for
the script-land.
Robin
Sounds good to me. I'll update the notice script to use the new BiF when it exists. 
.Seth
Do we still need the tags once we have unique connids for grepping?
It might be worthwhile still. It was interesting to me to see all of the notices attached to a connection. I'm a big proponent of browsing Bro logs and I like anything that makes my browsing experience better.
.Seth
> Do we still need the tags once we have unique connids for grepping?
It might be worthwhile still. It was interesting to me to see all of the notices attached to a connection.
Seems you get that already if the notice just includes the connid. Where
it would come up short is if you *don't* want all the notices (since there
are a zillion boring ones), or if a given notice might have a tag associated
with multiple connections (I don't think we do this presently, but in
principle it would make sense).
Vern
I did this in the new policy scripts yesterday. It makes it much easier to search for connections with Notices if the notice id is included in the conn log. We could implement this modularly though so that the notices (and the whole notice column itself) is only included if the script that implements that is loaded. It should get us the best of both depending on what you need.
.Seth