Would someone be kind enough to explain the difference between
tcp_keepalive_intvl and tcp_keepalive_time?
Documentation/filesystems/proc.txt says tcp_keepalive_time is the interval
between sending keepalive probes, but doesn't mention tcp_keepalive_intvl...
A quick grep through the source code says tcp_keepalive_intvl wanders through
keepalive_intv_when which is used in tcp_keepalive_time in a way that sort of
implies it's the timeout between keapalive packets. So what's
tcp_keepalive_time?
The problem I'm trying to track down is ssh connections where the connection
times out but the session doesn't go away until a key is pressed. (I.E.
blocking reads don't notice the connection going down underneath them, not
even if left overnight.)
It's kind of frustrating, actually...
Rob
> Would someone be kind enough to explain the difference between
> tcp_keepalive_intvl and tcp_keepalive_time?
> Documentation/filesystems/proc.txt says tcp_keepalive_time is the
interval
> between sending keepalive probes, but doesn't mention
tcp_keepalive_intvl...
tcp starts a keepalive timer for each connection. if the connection is idle
for tcp_keepalive_time seconds, it starts sending probes to the other end.
It sends a maximum of tcp_keepalive_probes each tcp_keepalive_intvl
seconds apart, and if the other end hasnt responded by then, it drops the
connection.
default values:
tcp_keepalive_intvl = 75 seconds
tcp_keepalive_probes = 9
tcp_keepalive_time = 7200 seconds (2 hours)
> The problem I'm trying to track down is ssh connections where the
connection
> times out but the session doesn't go away until a key is pressed. (I.E.
> blocking reads don't notice the connection going down underneath them,
not
> even if left overnight.)
not clear from the info here whats happening in your case...
(stats?)
> Rob
thanks,
Nivedita
On Saturday 09 February 2002 11:40 pm, Nivedita Singhvi wrote:
> > Would someone be kind enough to explain the difference between
> > tcp_keepalive_intvl and tcp_keepalive_time?
> > Documentation/filesystems/proc.txt says tcp_keepalive_time is the
>
> interval
>
> > between sending keepalive probes, but doesn't mention
>
> tcp_keepalive_intvl...
>
> tcp starts a keepalive timer for each connection. if the connection is idle
> for tcp_keepalive_time seconds, it starts sending probes to the other end.
> It sends a maximum of tcp_keepalive_probes each tcp_keepalive_intvl
> seconds apart, and if the other end hasnt responded by then, it drops the
> connection.
Thanks.
Patch to proc.txt:
--- linux/Documentation/filesystems/proc.txt Wed Nov 7 17:39:36 2001
+++ linux/Documentation/filesystems/proc.bak Sun Feb 10 02:46:55 2002
@@ -1421,8 +1421,14 @@
tcp_keepalive_time
------------------
-How often TCP sends out keep alive messages, when keep alive is enabled. The
-default is 2 hours.
+Number of seconds a connection must remain inactive before sending the first
+keep alive probe, when keep alive is enabled. The default is 7200 (2 hours).
+
+tcp_keepalive_intvl
+-------------------
+
+Number of seconds a keep alive probe must go unanswered before sending
+another one.
tcp_syn_retries
---------------
> not clear from the info here whats happening in your case...
> (stats?)
SuSE is being annoying in a way Red Hat wasn't. The box has a 2.4.6
kernel on it, I'll probably upgrade that before pursuing this much further
(which I won't be in a position to do until I physically get back to
Austin...) Since I've been playing with Linux From Scratch recently, I
ight throw the system I've put together on there so I at least know what
the heck it's all doing. :)
What kind of packets are keepalive packets, by the way? (I don't think
the firewall rules are filtering them out, but I can't be sure.)
> > Rob
>
> thanks,
> Nivedita
Rob again. :)
> What kind of packets are keepalive packets, by the
> way? (I don't think the firewall rules are filtering
> them out, but I can't be sure.)
> Rob again. :)
Thanks for correcting the documentation - it was out of date and erroneous.
The keepalive packets are simple tcp segments sent on the connection:
- no data
- ack # is next expected byte
- sequence # is a stale (byte already acked by the other end) one, so that
the
other end is forced to send an ack in return (as it receives an out of
window
sequence #).
I cant imagine how a firewall would be filtering them..
thanks,
Nivedita
On Monday 11 February 2002 03:51 pm, Nivedita Singhvi wrote:
> The keepalive packets are simple tcp segments sent on the connection:
>
> - no data
> - ack # is next expected byte
> - sequence # is a stale (byte already acked by the other end) one, so that
> the
> other end is forced to send an ack in return (as it receives an out of
> window
> sequence #).
>
> I cant imagine how a firewall would be filtering them..
The firewall is also doing IP Masquerading/transparent proxying/port
forwarding as part of a VPN setup (both source and destination NAT). So
iptables' connection tracking might be timing out, and/or interfering with
the keepalive packets. (Maybe the keepalive packets aren't making it through
NAT? That's my current theory. I know that's got a timeout after which it
forgets a masqueraded connection, and the same probably applies to the other
forms of NAT. My current theory is that keepalive packets aren't keeping NAT
connections alive...)
> thanks,
> Nivedita
Rob