Hi:
I believe this particular timer is a general timer used to track inactivity for all protocols (but someone can correct me if I’m wrong :). Maybe try tuning the following:
const tcp_inactivity_timeout = 5 min &redef;
const udp_inactivity_timeout = 1 min &redef;
const icmp_inactivity_timeout = 1 min &redef;
Reference: http://www.notary.icsi.berkeley.edu/sphinx-git/scripts/base/init-bare.bro.html#id-udp_inactivity_timeout
Also, I believe it’s possible to set timeouts per-connection based on properties of the established connections. For an example of doing this / how this might be useful, take a look at:
https://bro.org/sphinx/scripts/base/protocols/conn/inactivity.bro.html
Re: interpreting prof.log output – a few notes from my experience:
There should be lines that include the number of connections currently active for each major protocol type, e.g:
Conns: tcp=1/130 udp=1/70 icmp=0/0
Syntax here is: tcp=/ udp=/ icmp=/
The line following the above includes more detailed connection overhead information:
Conns: total=6528 current=2/2 ext=0 mem=9312K avg=4656.0 table=24K connvals=6K
A few notes about fields that might be useful there:
- total=total number of connections (aggregate: not just at this particular moment)
- current=X/Y: X and Y are two counts that will usually differ to some extent, but both count the number of connections observed
- X: the number of active connections in total (not necessarily all of which are kept in state tables)
- Y: the number of connections stored in bro’s state tables (tcp + udp + icmp) at this moment in time
- avg=average memory use (in bytes) per active connection
- table=total amount of memory used by the state tables (tcp + udp + icmp)
‘avg’ and ‘table’ are only recorded occasionally because computing these values can be expensive. When that “Global_sizes …” output is included in a log entry, these numbers will be accurate. Otherwise, they will be 0.
For an idea of the overhead associated with the Timer objects themselves (read: the overhead for the timers isn’t included in the overhead computed for the connection state), take a look at the line that looks something like:
Timers: current=19 max=19 mem=1K lag=0.00s
*current=number of timers currently active in total
*max=maximum number of timers ever active at once
*mem=total memory consumed by all of the currently active timers (usually pretty small compared to other things, though)
Also, one other note: under ‘Threads’, there’s a bunch of lines that look something like:
http/Log::WRITER_ASCII in=11318 out=10882 pending=0/0 (#queue r/w: in=11318/11318 out=10882/10882)
ssl/Log::WRITER_ASCII in=10931 out=10878 pending=0/0 (#queue r/w: in=10931/10931 out=10878/10878)
files/Log::WRITER_ASCII in=10989 out=10792 pending=0/0 (#queue r/w: in=10989/10989 out=10792/10792)
dhcp/Log::WRITER_ASCII in=1031 out=1029 pending=0/0 (#queue r/w: in=1031/1031 out=1029/1029)
Generally, pending X/Y will describe how much memory is currently being consumed (relatively speaking) by messages waiting to be written to a log file / that have been read from that input source but not yet processed by bro.
A pending X/Y that grows steadily over time is an indication that bro could eventually run out of room to store outstanding log / input framework messages, and that these messages could eventually come to consume so much memory that the worker would thrash the machine into sweet digital oblivion.
Hope something in there is useful,
Gilbert
