Scheduling events are immediatly executed

Zeek
1

Hello,

I'm working with BRO and have a problem. I want to use scheduling but it doesn't seem to work. Alle tests, that I wrote, are immidiatly ready. I have seen the ticket https://bro-tracker.atlassian.net/browse/BIT-747 and have tried to reschedule. But it doesn't work. The rescheduled event is either missing, when no files are read, or immidiatly ready when files are read.

Have someone tipps for me or is there any documentation, how the scheduling and eventing are work in BRO?

For example this is the test I use:

#@TEST-EXEC: bro -b -C -r $TRACES/10000.pcapng %INPUT > output 2> output.err
#@TEST-EXEC: test -f output
#@TEST-EXEC: btest-diff output
#@TEST-EXEC: test -f output.err
#@TEST-EXEC: btest-diff output.err

event e2() {
  print "e2";
}

function scheduleEvent(){
  print "f1";
  schedule 100sec { e2() };
}

event e1() {
  print "e1";
  scheduleEvent();
}

event bro_init() {
  schedule 100sec { e1() };
}

The trace file can be any pcap file.

consistec Engineering & Consulting GmbH
Jan Muthreich - Software Engineer

2

One thing to keep in mind for schedule is that it's relative to
"network time", i.e., the packet timestamps in the trace. When you say
100s, it's not going to wait for 100s of wall clock time to pass, but
will trigger the event once the packet timestmaps have covered 100s.
When working offline from a trace, like in your case, that often feels
like "immediately" if the input is short. Could that be it?

Robin

3

Thank you. I have an Input READER_ASCII in use, which need Input::force_update. It reads from a linux pipe. How can we schedule this operation if no network traffic is in the line?

Mit freundlichen Grüßen
Jan Muthreich

4

Hi all,

is Bro's event schedule depending on "input" from the network / trace file? I.e., does it stop processing ASCII reader input if there's no more network activity?

This might not be a big deal in production rollouts when bro is listing to real network interfaces, but in test scenarios (with btest) it looks to me as if bro stops processing other input, once the pcap files have been consumed completely. Is there any work around / best practice on how such situations can be handled in tests?

Thanks for your help!

Dirk

5

Bro normally terminates once it has read the whole trace. You can
prevent that by setting exit_only_after_terminate to true; then it
will keep running (and proecessing other input) until you call the
built-in function terminate(). You can see this in the input framework
tests in testing/btest/scripts/base/frameworks/input.

The other piece to this (and the original question) is that it's a
fundamental challenge to process a trace while also doing things that
happen in real-time (input framework, but also any communication with
external processes). Bro can read a trace much more quickly than it
would normally process the same traffic during live operation, meaning
it will get out of sync with any other activity still happening "just"
in real time.

There's a work-around for testing purposes: Bro has a switch
"--pseudo-realtime" that articifially delays processing a trace: after
reading each packet, it inserts a delay corresponding to the timestamp
gap to the next packet. In that way, it "simulates" real-time
processing by not getting head of what a live Bro would do. For
example, the test
testing/btest//scripts/policy/protocols/ssl/validate-certs-cluster.bro
uses this to set up a Bro cluster of multiple processes for X509 cert
validation while reading the input from a trace.

Robin