Why isn't it possible to lower TCP values of running SSH session?

[john smith]

I am running OpenSSH_6.7p1 on Slackware 14.1 x64. I haven't modified
a stock config. On Linux TCP timeouts are controlled by these 3
files:

$ cat /proc/sys/net/ipv4/tcp_keepalive_time \

/proc/sys/net/ipv4/tcp_keepalive_intvl \
/proc/sys/net/ipv4/tcp_keepalive_probes

7200
75
9

These are their default values. I modified them to 3, 1, 1
respecitively before establishing a new SSH connection. After
establishing an SSH connection to a machine next to me I unplugged a
network cable on the remote machine and had to wait for 3 seconds for
the SSH session to be terminated by Linux. This is what I
expected. Next, I connected again and while SSH session was already
opened I changed values to their defaults - 7200, 75, 9. After
unplugging a network cable I wasn't disconnected within 3 seconds. It
made me think that it's possible to modify TCP timeouts of opened TCP
sockets such as SSH connections. However, after connecting to the same
machine again I changed timeout values to 3, 1, 1 again. To my
surpires, after unplugging a network cable on the remote side I wasn't
disconnected within 3 seconds. It seems it's only possible to increase
TCP timeout values when SSH session is already opened but not to lower
them. Why? Is it Linux or OpenSSH thing?

[Damien Miller]

TCP is the kernel's responsibility. I guess that these values get
copied into each TCB from the copy managed via proc at connection
start time, but never updated afterwards.

You might want to consider using protocol-level keepalives:
ServerAliveInterval/ServerAliveCountMax in ssh_config.

-d

Post by john smith
I am running OpenSSH_6.7p1 on Slackware 14.1 x64. I haven't modified
a stock config. On Linux TCP timeouts are controlled by these 3
$ cat /proc/sys/net/ipv4/tcp_keepalive_time \

/proc/sys/net/ipv4/tcp_keepalive_intvl \
/proc/sys/net/ipv4/tcp_keepalive_probes

7200
75
9
These are their default values. I modified them to 3, 1, 1
respecitively before establishing a new SSH connection. After
establishing an SSH connection to a machine next to me I unplugged a
network cable on the remote machine and had to wait for 3 seconds for
the SSH session to be terminated by Linux. This is what I
expected. Next, I connected again and while SSH session was already
opened I changed values to their defaults - 7200, 75, 9. After
unplugging a network cable I wasn't disconnected within 3 seconds. It
made me think that it's possible to modify TCP timeouts of opened TCP
sockets such as SSH connections. However, after connecting to the same
machine again I changed timeout values to 3, 1, 1 again. To my
surpires, after unplugging a network cable on the remote side I wasn't
disconnected within 3 seconds. It seems it's only possible to increase
TCP timeout values when SSH session is already opened but not to lower
them. Why? Is it Linux or OpenSSH thing?
--
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[john smith]

Post by Damien Miller
TCP is the kernel's responsibility. I guess that these values get
copied into each TCB from the copy managed via proc at connection
start time, but never updated afterwards.

This had to happen but the question is why is it possible to increase
a timeout but not to decrease it.

[john smith]

Post by john smith

Post by Damien Miller
TCP is the kernel's responsibility. I guess that these values get
copied into each TCB from the copy managed via proc at connection
start time, but never updated afterwards.

This had to happen but the question is why is it possible to increase
a timeout but not to decrease it.

Well I just did an iteresting test. If I set timeout values to 10, 1,
1, connect to remote, change timeout values to 3, 1, 1 and wait for 10
seconds inside SSH session, then unplug a network cable on the remote
it only takes 3 seconds to close an expired session. I also tried to
set timeout values to 60, 1, 1, connect to remote, change timeout
values to 3, 1, 1, wait for 60 seconds, unplug the cable and again it
only took 3 seconds to close a frozen session. I think it has
something to do with the following piece of code inside Linux kernel:

/linux/kernel/time/timer.c

if (timer_pending(timer) && timer->expires == expires)
return 1;

return __mod_timer(timer, expires, false, TIMER_NOT_PINNED);

I think that after changing 7200 to 3 I would also be automatically
disconnected after 3 seconds but only after first 7200 seconds of
active session. However, I would be glad if someone more experienced
could confirm my assumptions (I am sure there are such people here).

[Salvador Fandino]

Post by john smith

Post by Damien Miller
TCP is the kernel's responsibility. I guess that these values get
copied into each TCB from the copy managed via proc at connection
start time, but never updated afterwards.

This had to happen but the question is why is it possible to increase
a timeout but not to decrease it.

Some years ago I found that the implementation of TCP keepalive on Linux
is not reliable.

Inside the kernel, the code that does the keep-alive thing is not called
unless the output socket buffer is empty, otherwise the regular handling
for the TCP output stream that just retries sending the queued data with
increasing (IIRC, x2) delays is applied and it uses a different set of
counters and timeouts that are not affected by the tcp_keepalive_*
parameters.

That bug is probably still there.

[Peter Stuge]

Post by Salvador Fandino
Some years ago I found that the implementation of TCP keepalive on Linux
is not reliable.

..

Post by Salvador Fandino
That bug is probably still there.

Did you file a report at bugzilla.kernel.org?


//Peter

[Salvador Fandino]

Post by Peter Stuge

Post by Salvador Fandino
Some years ago I found that the implementation of TCP keepalive on Linux
is not reliable.

..

Post by Salvador Fandino
That bug is probably still there.

Did you file a report at bugzilla.kernel.org?

I discussed the issue on the Linux networking mailing list but I went
nowhere.