As I am aware, Bro has steadily moved toward a multi-threaded approach to logging at the least. For an analyzer that I’ve been developing as part of my research, I am curious to know if network_time remains coherent with the network time given in pcap files and live capture. If not, is there a more accurate variable available?
Of note: I’ve never really observed a discrepancy between the pcap files and reported network time through the event system. Gilbert Clark and I had a small discussion on this and I feel that from what I’ve seen in the source code, network_time is likely fine, but I thought I’d get the answer from the folk who know the source quite a bit better than I do.
Best,
There are several things going into this from what I understand. network_time is obviously driven by the packet timestamps so it's going to represent the most recent packet received. Do to stream reassembly and it's interaction with the event queue it's possible that there are misrepresentations in the value returned from network_time().
If you use current_time(), that's going to get the current clock time but that could also be misleading due to latency in the event queue. The best answer I have is like most things in Bro, you have to transition your mind away from packets and if what you are trying to do is intrinsically some packet level thing Bro might not be the right too (unless you are working in the core where you can absolutely do packet level work).
On the upside, Bro does flush it's event queue after every single packet so it's not like you are going to see large latency due to the event queue.
Bro's event queue and stream parsing were not threaded either. Only the logging and input frameworks which almost certainly won't affect anything you are doing.
.Seth