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 Conn.cc.
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?