TCP SYN timeouts


while working on I found some
oddities. But see also

Bro has:
  * tcp_SYN_timeout
  * tcp_attempt_delay
both are set to 5sec.

Both can time out a TCP connection for which only SYNs are seen.
However, tcp_attempt_delay is used only when the the connection_attempt
event has a script level handler. tcp_attempt_delay is installed on the
*first* SYN packet. Thus tcp_attempt_delay always triggers relative to
the first SYN packet (and did this even before #77 was applied. I.e.,
#77 did not change the timer behavior)
Note that conn.bro has a connection_attempt handler.

tcp_SYN_timeout is used when TCP_Analyzer is instantiated to set the
ExpireTimer() (which can also happen on a pure data packet, BTW). The
ExpireTimer only does any "expiring"
    if ( Conn()->LastTime() + tcp_connection_linger < t )
(so, no check for tcp_SYN_timeout). However, ExpireTimer() checks
whether there is an connection_attempt handler and if there's one it
will not generate connection_timeout() events for connections that only
had SYNs and no other packets. (ExpireTimer otherwise only handles
connections for which at least one side is already closed)

Then there's also the tcp_inactivity_timeout, which is set to 5min and
managed in

There's a dated documentation (pre-DPD) in the Wiki concerning these
It seems that originally
  tcp_connection_linger < tcp_SYN_timeout < tcp_attempt_delay
which makes sense given the way these timers interact, but since we now
  tcp_SYN_timeout == tcp_attempt_delay < tcp_connection_linger
the overall timer behavior is weird.

Note, the connection compressor currently *only* uses tcp_attempt_delay,
and bases it on the time of the last SYN packet.

So, the question is: what should we do?