# TCP idle timer expiry

**URL:** <https://community.zeek.org/t/tcp-idle-timer-expiry/1073>\
**Category:** Zeek\
**Created:** [December 1, 2006, 9:34am UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073 "2006-12-01T09:34:48Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jaya\_Dhanesh](https://avatars.discourse-cdn.com/v4/letter/j/7feea3/32.png) [@Jaya\_Dhanesh](https://community.zeek.org/u/Jaya_Dhanesh)\
**Post date:** [December 1, 2006, 9:34am UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073/1 "2006-12-01T09:34:48Z")

</div>

Hi,

If the tcp connection is idle for some time, the connection\_state\_remove  
event handler is getting called.  
So the subsequent packets in the same connection doesn't get logged.

How can I increase the tcp idle time out? The increase in the timer is also  
not the best solution.  
Is there a way where the packets gets logged even after BRO removes the  
connection from the table?

Thanks,  
Dhanesh.

---

<div class="post-metadata">

**Author:** ![Scott\_Campbell](https://avatars.discourse-cdn.com/v4/letter/s/54ee81/32.png) [@Scott\_Campbell](https://community.zeek.org/u/Scott_Campbell)\
**Post date:** [December 1, 2006, 7:11pm UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073/2 "2006-12-01T19:11:51Z")

</div>

Jaya Dhanesh wrote:

> Hi,
> 
> If the tcp connection is idle for some time, the connection\_state\_remove  
> event handler is getting called.  
> So the subsequent packets in the same connection doesn't get logged.
> 
> How can I increase the tcp idle time out? The increase in the timer is also  
> not the best solution.

You can reconfigure several timer values such as:

redef tcp\_SYN\_timeout = X secs;  
redef tcp\_attempt\_delay = X secs;

redef tcp\_inactivity\_timeout = X mins;  
redef udp\_inactivity\_timeout = X secs;  
redef icmp\_inactivity\_timeout = X secs;

which might help out some. See heavy-analysis.bro for a better list.

> Is there a way where the packets gets logged even after BRO removes the  
> connection from the table?

You will get a \*new\* connection for post-timed out data if the pcap  
expression allows for ACK flagged packets to be seen (such as 80/tcp  
with the http analyzer loaded). If not, then the FIN/RST ought to be  
picked up as an additional connection.

If your configuration is not seeing much in the way of traffic, then it  
is possible to turn the timeout values quite high. They have been tuned  
to their current values to prevent state explosion for busy sites.

scott

---

<div class="post-metadata">

**Author:** ![Jim\_Mellander](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@Jim\_Mellander](https://community.zeek.org/u/Jim_Mellander)\
**Post date:** [December 2, 2006, 12:27am UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073/3 "2006-12-02T00:27:08Z")

</div>

Could someone explain what tcp\_attempt\_delay is used for? It seems that  
it may be relevant to a script problem that I am experiencing, where a  
'new\_connection' event is occurring 5 seconds after the packet is  
received (an unanswered SYN), 5 seconds being also the default value of  
tcp\_attempt\_delay - so I am drawing a (possibly unwarranted) connection  
between the value of tcp\_attempt\_delay and the time delay I am experiencing.

Is there perhaps a different event that I should be looking at, or can  
this value be turned to zero without negative effect? - I need to  
respond immediately to an incoming packet.

The application is a custom 'catch-and release' blocking script. We  
block a host when it scans, then unblock after an interval of  
quiescence, to preserve a working set of currently threatening hosts.  
When a host that was unblocked as much as sends a single packet, we want  
to immediately reblock. This, of course, requires immediate response -  
waiting for a 5 second interval is unacceptable.

On an older version of Bro, the new\_connection event was triggered  
immediately on receipt of the first packet, and the 'catch-and-release'  
mechanism worked correctly, now we seem to have this 5 second delay.

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [December 4, 2006, 6:39pm UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073/4 "2006-12-04T18:39:06Z")

</div>

This might be an (unintentional) artifact of the connection  
compressor. I'll look into it.

Robin

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/tcp-idle-timer-expiry/1073/5 "2022-05-06T15:38:04Z")

</div>