> > > Since updating to 2.0.34 i encounter that ssh/rlogin
> > > connections are dropped after some idle time.
> > > I have seen a message (on linux-kernel?) which provided
> > > a workaround but cannot find it anymore.
> Thanks for your response but your guess is (at least partially)
> wrong. This is happening with HP-UX systems.
>
> I'm used to have a couple of dtterm/hpterm windows on our HP-UX
> systems. After uprading to 2.0.34 they are closed after some
> period of inactivity. This is probably related to keep alive handling.
>
> I remember i saw a message somewhere (which i can't find anymore)
> that this is a side effect of a 2.0.34 TCP change. The quick fix
> was to replace the return value at the end of a tcp_* function.
> However i can't remember the details and this is getting
> annoying ...
Hi Michael,
Below is my original post on linux-net and an answer from Alan Cox
about this problem:
Greetings
Rob van Nieuwkerk
******************************************************************************
From: Rob van Nieuwkerk <robn@verdi.et.tudelft.nl>
Subject: 2.0.34 BUG: TCP KeepAlive processing
To: alan@lxorguk.ukuu.org.uk
Date: Sun, 7 Jun 1998 12:48:20 +0200 (MET DST)
Cc: robn@verdi.et.tudelft.nl (Rob van Nieuwkerk), linux-net@vger.rutgers.edu
I think that there is a bug in the 2.0.34 handling of (at least) BSD
type TCP KeepAlive probing. The symptom is that a SSH session from an
Ultrix to Linux machine gets aborted after some time of inactivity.
Below are 2 tcpdump traces. In the first one you can see that 2.0.34
does not ack the probes from the Ultrix machine. In the the second one
you can see that it works OK in 2.0.33.
This change in behaviour is related to a change in net/ipv4/tcp_input.c:
the last statement of tcp_ack() was changed from "return 1;" to
"return 0;" in 2.0.34 (line 1728). Changing it back to the 2.0.33
one gives back the wanted behaviour.
Greetings,
Rob van Nieuwkerk
verdi = Linux-2.0.34, moondawn = Ultrix Worksystem V2.1 (Rev. 14):
------------------------------------------------------------------
11:14:44.599288 verdi.et.tudelft.nl.1022 > moondawn.et.tudelft.nl.ssh: P 684:704(20) ack 2052 win 32696 (DF) [tos 0x10]
11:14:44.849316 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: P 2052:2072(20) ack 704 win 4096
11:14:44.869318 verdi.et.tudelft.nl.1022 > moondawn.et.tudelft.nl.ssh: . ack 2072 win 32696 (DF) [tos 0x10]
11:14:50.739968 verdi.et.tudelft.nl.1022 > moondawn.et.tudelft.nl.ssh: P 704:724(20) ack 2072 win 32696 (DF) [tos 0x10]
11:14:50.989996 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: P 2072:2092(20) ack 724 win 4096
11:14:51.009998 verdi.et.tudelft.nl.1022 > moondawn.et.tudelft.nl.ssh: . ack 2092 win 32696 (DF) [tos 0x10]
11:14:51.150014 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: P 2092:2200(108) ack 724 win 4096
11:14:51.170016 verdi.et.tudelft.nl.1022 > moondawn.et.tudelft.nl.ssh: . ack 2200 win 32696 (DF) [tos 0x10]
**** start of moondawn->verdi KeepAlive probes (verdi doesn't respond)
11:16:06.098315 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:17:21.096624 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:18:36.104937 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:19:51.093249 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:21:06.111566 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:22:21.099883 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:23:36.108203 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:24:51.106525 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: . 2199:2200(1) ack 723 win 4096
11:26:06.114849 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1022: R 2200:2200(0) ack 724 win 4096
*** moondawn user looses shell on verdi because of "Connection timed out"
verdi = Linux-2.0.33, moondawn = Ultrix Worksystem V2.1 (Rev. 14):
------------------------------------------------------------------
11:39:14.891082 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: P 704:724(20) ack 1992 win 32696 (DF) [tos 0x10]
11:39:14.921085 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: P 1992:2012(20) ack 704 win 4096
11:39:14.941088 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2012 win 32696 (DF) [tos 0x10]
11:39:14.991094 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: P 724:744(20) ack 2012 win 32696 (DF) [tos 0x10]
11:39:15.131110 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: P 2012:2032(20) ack 724 win 4096
11:39:15.151112 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2032 win 32696 (DF) [tos 0x10]
11:39:15.251124 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: P 2032:2052(20) ack 744 win 4096
11:39:15.271126 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2052 win 32696 (DF) [tos 0x10]
11:39:15.401141 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: P 2052:2160(108) ack 744 win 4096
11:39:15.421144 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2160 win 32696 (DF) [tos 0x10]
**** start of moondawn->verdi KeepAlive probes (verdi responds)
11:40:30.149876 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: . 2159:2160(1) ack 743 win 4096
11:40:30.149876 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2160 win 32696 (DF) [tos 0x10]
11:41:45.158642 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: . 2159:2160(1) ack 743 win 4096
11:41:45.158642 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2160 win 32696 (DF) [tos 0x10]
11:42:59.978403 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: . 2159:2160(1) ack 743 win 4096
11:42:59.978403 verdi.et.tudelft.nl.1023 > moondawn.et.tudelft.nl.ssh: . ack 2160 win 32696 (DF) [tos 0x10]
11:44:14.987168 moondawn.et.tudelft.nl.ssh > verdi.et.tudelft.nl.1023: . 2159:2160(1) ack 743 win 4096
*** moondawn user can keep shell on verdi forever
******************************************************************************
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: 2.0.34 BUG: TCP KeepAlive processing
To: robn@verdi.et.tudelft.nl (Rob van Nieuwkerk)
Date: Sun, 7 Jun 1998 16:23:07 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, robn@verdi.et.tudelft.nl,
linux-net@vger.rutgers.edu
> This change in behaviour is related to a change in net/ipv4/tcp_input.c:
> the last statement of tcp_ack() was changed from "return 1;" to
> "return 0;" in 2.0.34 (line 1728). Changing it back to the 2.0.33
> one gives back the wanted behaviour.
Yep. The problem is putting it back to the 2.0.33 behaviour also allows a
third party using only remote packet counts (eg snmp access) to find the
sequence number of a tcp session and attack it. (Linux and other OS's)
I'll look at work arounds in .35 - the obvious one is to ack just 1 byte
out of window in the direction used by old BSD keepalives.
Alan
******************************************************************************
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu