openssh unix dev - Nov 2015 - Why isn't it possible to lower TCP values of running SSH session?

On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org>
wrote:
> 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.

-- 
<wempwer at gmail.com>

On Tue, Nov 24, 2015 at 1:05 AM, john smith <wempwer at gmail.com>
wrote:
> On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org>
wrote:
>> 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).
-- 
<wempwer at gmail.com>

On 11/24/2015 01:05 AM, john smith wrote:
> On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org>
wrote:
>> 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.

Salvador Fandino wrote:
> Some years ago I found that the implementation of TCP keepalive on Linux
> is not reliable.
..
> That bug is probably still there.
Did you file a report at bugzilla.kernel.org?


//Peter