Re: TCP bug in 2.1.22+

Eric.Schenk@dna.lth.se
Sun, 06 Apr 1997 11:22:50 +0200


bofh@snoopy.virtual.net.au <bofh@snoopy.virtual.net.au> writes:
> Here is a set of trace logs when my systems are experiencing
>the TCP problems. The server (203.29.16.4) is running 2.1.29
>and the client (203.29.19.1) is running 2.1.31. They are directly
>connected via a 33K6 modem link running PPP.

[Aside, your mailer is sending paragraphs as single lines. Please fix this.]

I can't tell for sure what is going wrong here because you have sent
abreviated traces that aren't synchronized. If you don't give tcpdump
the "-S" option it will start numbering packets with sequence number
1 on the first packet it gets on a connection. This means that unless
both ends of the tcpdump are started before the tcp connection starts
the numbering on the two dumps will be different. Also, it's generally
important to see the entire tcp session in the dumps, just seeing a
portion of the middle does nothing to tell me about the conditions
leading up to the problem.

Now, having said that, I suspect your problem is an old problem
that I fixed in the 2.0.X code last year. Short version, we
keep clocks that are too accurate, this makes the classic retransmission
timeout algorithm time out a bit too easily when the packet transmission
time is dominated by the length of the packet, as on a serial link.
This eventually leads to stalls in the tcp when it times out and
resends a window, in your case about 8k.

In any case, I will be putting the same fix, or something equivalent,
into the 2.1.X tcp code shortly. In the mean time, can you please send
me complete tcpdump traces so I can check if the problem you are seeing
really is what I think it is.

Thanks,

-- 
Eric Schenk                               www: http://www.dna.lth.se/~erics
Dept. of Comp. Sci., Lund University          email: Eric.Schenk@dna.lth.se
Box 118, S-221 00 LUND, Sweden   fax: +46-46 13 10 21  ph: +46-46 222 96 38