Re: 220.127.116.11 bug? per-socket TCP keepalive settings
From: David S. Miller
Date: Thu Aug 18 2005 - 17:54:48 EST
From: Sebastian Kuzminsky <seb@xxxxxxxxxxx>
Date: Thu, 18 Aug 2005 16:07:32 -0600
> Linux provides 3 non-standard TCP socket options for tweaking the
> keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT,
> and TCP_KEEPINTVL. The values set on a socket with these options should
> override the system-wide default.
There is a fourth setting, the SO_KEEPALIVE socket option, which
also must be enabled explicitly by the application to enable keepalives.
It defaults to off. Your application sets this, so all is fine so far.
> The right thing is to wait IDLE seconds, then send CNT probes INTVL
> seconds apart, then reset the TCP connection.
> The wrong behavior I'm seeing is the first probe goes out on schedule,
> and sometimes a few more probes go out on schedule, but then it stops
> sending anything at all. It doesnt send the last of the probes, and it
> doesnt send the reset. The connection is stuck in the ESTABLISHED state,
> according to netstat.
Your test case is questionable, because you do not receive even one
ACK in established state, thus the tp->rcv_tstamp variable has no
way to get initialized. The only ACK you receive is the one in
response to the connection setup SYN, and we don't initialize
tp->rcv_stamp for that ACK.
The keepalive time checks absolutely require that tp->rcv_tstamp
has a valid value, and until you process an ACK in ESTABLISHED
state it does not.
If you send successfully or receive successfully at least one byte
over the connection, and thusly process at least one ACK in
ESTABLISHED state, I think you'll find that the keepalives behave
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/