[Bro] policy event engine

Yuriy vin123456 at mail.ru
Fri Jan 21 07:36:40 PST 2011


Thank you for the quick reply,
Can you understand me (at least briefly) what is the reason of "...the
notion of time in Bro is driven forward by the packet timestamps...", why
not internal clock?
As I understood the only way to change such behavior (packet timestamps
clock driven) is "If remote communication is enabled, the internal time will
be clock driven...". Can one little detail, please?


-----Original Message-----
From: Seth Hall [mailto:seth at icir.org] 
Sent: Friday, January 21, 2011 6:08 PM
To: Yuriy
Cc: Bro at bro-ids.org
Subject: Re: [Bro] policy event engine


On Jan 21, 2011, at 9:56 AM, Yuriy wrote:

> I can`t understand scripts asynchronous call behavior. When I pointing 20
second in table`s data type attributes "&create_expire=20sec", I find
unpredictable behavior

Unpredictable but expected. :)  Timers in Bro aren't "hard".  They will be
dispatched when Bro gets around to them, not at the exact moment the timer
was scheduled to fire.  The only thing you can be assured of is that it
won't be dispatched prior to the time which is set.

> : the table`s item removed not in 20 seconds, it can be removed after
25,30 etc seconds. As I found it is depending on how many packets in the
network: if there is no packets after timer value, my timer will never
expire.

By default, the notion of time in Bro is driven forward by the packet
timestamps which means that timer expirations will go accordingly.  
No packets == no time advancement == no timer expiration.

If remote communication is enabled, the internal time will be clock driven.
I don't know offhand if that requires an actual connection or if just
holding open a socket will work.

> And when the first packet appear, the timer immediately expire (but, for
example, has been more than a few hours).

I don't understand what you are saying here.  Which timer expires
immediately?

  .Seth




More information about the Bro mailing list