[4461] in linux-net channel archive
tcp bug?
daemon@ATHENA.MIT.EDU (Matthias Welwarsky)
Wed Sep 18 15:49:39 1996
Date: Wed, 18 Sep 1996 18:54:21 +0200
From: Matthias Welwarsky <dg2fef@uet.th-darmstadt.de>
Reply-To: dg2fef@uet.th-darmstadt.de
To: linux-net@vger.rutgers.edu
Hello there.
I found a rather strange behaviour in linux' kernel-tcp. Kernel version
is 2.0.20.
This is the Situation:
I have a ftp-connection to a remote host dl4vbp, trying to transmit a
file. Looks
normal until the point where it first times out and retransmits (time
code 17:52:38.227488).
>17:51:50.057488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 10095 win 31744 [tos 0x8]
>17:51:50.057488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12258:12979(721) ack 1 win 31744 [tos 0x8]
>17:52:03.287488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 11537 win 31744 [tos 0x8]
>17:52:03.287488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12979:13700(721) ack 1 win 31744 [tos 0x8]
>17:52:03.287488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 13700:14421(721) ack 1 win 31744 [tos 0x8]
>17:52:06.367488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 12258 win 31744 [tos 0x8]
>17:52:06.367488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: . 14421:15142(721) ack 1 win 31744 [tos 0x8]
>17:52:06.367488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 15142:15863(721) ack 1 win 31744 [tos 0x8]
>17:52:38.227488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12258:12979(721) ack 1 win 31744 [tos 0x8]
>17:54:14.567488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12258:12979(721) ack 1 win 31744 [tos 0x8]
now I get an ACK for the missing segment. It is definitely the ACK for
the first transmitted 12258:12979,
not for one of the retransmitted ones, because the TCP-Connection is
tunneld through a secure link-layer
(ax25-virtual circuit) that prevents frame losses. It also warrants that
packets going to and fro to arrive
exactly in the same sequence they were transmitted.
>17:54:19.517488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 12979 win 31744 [tos 0x8]
Now look at this: the kernel retransmits 12979:13700, but TWICE! within
some ten milliseconds.
>17:54:19.517488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12979:13700(721) ack 1 win 31744 [tos 0x8]
>17:54:19.547488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 12979:13700(721) ack 1 win 31744 [tos 0x8]
then another ACK arrives. Again this is the ACK for the first
transmitted 12979:13700, not for the
retransmitted one.
>17:54:22.697488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 13700 win 31744 [tos 0x8]
Same as above.. Goes the same way like before. Note that all ACKs
received belong to the original
segments, not to the retransmitted ones.
>17:54:22.697488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 13700:14421(721) ack 1 win 31744 [tos 0x8]
>17:54:22.727488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 13700:14421(721) ack 1 win 31744 [tos 0x8]
>17:54:24.797488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 14421 win 31744 [tos 0x8]
>17:54:24.797488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: . 14421:15142(721) ack 1 win 31744 [tos 0x8]
>17:54:24.817488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: . 14421:15142(721) ack 1 win 31744 [tos 0x8]
>17:54:28.127488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15142 win 31744 [tos 0x8]
>17:54:28.127488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 15142:15863(721) ack 1 win 31744 [tos 0x8]
>17:54:28.157488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 15142:15863(721) ack 1 win 31744 [tos 0x8]
>17:54:30.337488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
At this point the kernel has retransmitted all previously sent segments.
It now transmits the next segment
in sequence, 15863:16584. The ACKs coming in now belong to the
retransmitted segments, shows that in
fact nothing got lost, only the ACKs were delayed a bit.
>17:54:30.337488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 15863:16584(721) ack 1 win 31744 [tos 0x8]
>17:54:30.447488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:30.447488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:31.967488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:39.207488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:39.207488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:43.417488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:44.107488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:56.377488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
>17:54:58.577488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 15863 win 31744 [tos 0x8]
Next ACK belongs to 15863:16584 which is a "new one". After that
everyone is happy again.
>17:55:06.447488 dl4vbp.ampr.org.ftp-data > dg2fef-2.ampr.org.1259: . ack 16584 win 31744 [tos 0x8]
>17:55:06.447488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: . 16584:17305(721) ack 1 win 31744 [tos 0x8]
>17:55:06.447488 dg2fef-2.ampr.org.1259 > dl4vbp.ampr.org.ftp-data: P 17305:18026(721) ack 1 win 31744 [tos 0x8]
This is reproduceable, happens quite often when tcp starts
retransmitting.
Any idea?
--
Matthias
