From: "Eugene B. Berdnikov" <berd@elf.ihep.su>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org, Dave Miller <davem@redhat.com>
Subject: Re: Bug report: tcp staled when send-q != 0, timers == 0.
Date: Wed, 11 Apr 2001 14:16:45 +0400 [thread overview]
Message-ID: <20010411141645.B12573@elf.ihep.su> (raw)
In-Reply-To: <20010409184338.B1396@elf.ihep.su> <200104101738.VAA21467@ms2.inr.ac.ru> <20010411011901.A2029@fay.elferno.lo>
In-Reply-To: <20010411011901.A2029@fay.elferno.lo>; from Eugene B. Berdnikov on Wed, Apr 11, 2001 at 01:19:01AM +0400
Hello.
I'd like to make additional comments to my previous message.
On Wed, Apr 11, 2001 at 01:19:01AM +0400, Eugene B. Berdnikov wrote:
> The thing is that one machine (which run ssh client in my bug report)
> do send ACKs when ssh is SIGSTOP'ed. The other one does not send ACKs,
> but much more curious is that it does not send ACKs even when input
> buffer is filled, and client IS NOT stopped! :))) Hence connection dies
> due to retransmission timeout on the server side.
[...]
> Both hosts are running 2.2.17 on K6 processors, compiled via egcs-1.1.2,
> with minor differences in the kernel configuration.
My observation of the "buggy" 2.2.17 was on the host, connected via
modem and running ppp-2.4.0b2 with MTU=256. Today I got this kernel and
modules, and run it on another machine with Cel-450 and 3c590B-TX
ethernet card. It also exhibits loss of ACKs. My study shows, that
it depends upon MTU and keepalive flags:
mtu 382 + keepalive yes -> loss
mtu 382 + keepalive no -> ok
mtu 383 + any keepalive -> ok
I tested several values of MTU over and below 382, and it seems me that
value 382 is a boundary between normal and error behaviour.
Then I have tested kernel 2.2.14-5.0 from the RedHat-6.2 distribution on
the same machine (Cel-450 + 3c59x driver). It also shows loss of ACKs,
but with another MTU boundary and independently of keepalive:
mtu <= 420 + any keepalive -> loss
mtu >= 421 + any keepalive -> ok
At last, I tried several MTUs on 3d computer, running "right" 2.2.17, and
could not find conditions, under which any loss of ACKs can be detected.
So, the conclusion is that this loss depends upon kernel version,
configuration options and MTU on the interface. I suspect this is
another bug, accationaly found in discussion. :)
I complete my statements with the illustration dump. Commands were like
ifconfig ppp0 mtu 256
ssh -o 'keepalive yes' 194.190.166.31 \
'while true ; do cat /etc/passwd ; done' 2>&1 | less
tcpdump -nl host 194.190.166.31
[...]
10:20:11.196983 > 172.16.42.57.1023 > 194.190.166.31.ssh: . 655:655(0) ack 30120 win 15708 <nop,nop,timestamp 8830012 121274899> (DF) [tos 0x10]
10:20:11.266845 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121274900 8829912> (DF) [tos 0x10]
10:20:11.356837 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30324:30528(204) ack 655 win 32616 <nop,nop,timestamp 121274900 8829912> (DF) [tos 0x10]
10:20:11.426832 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30528:30732(204) ack 655 win 32616 <nop,nop,timestamp 121274902 8829919> (DF) [tos 0x10]
10:20:11.476844 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30732:30936(204) ack 655 win 32616 <nop,nop,timestamp 121274902 8829919> (DF) [tos 0x10]
10:20:11.546843 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30936:31140(204) ack 655 win 32616 <nop,nop,timestamp 121274962 8829928> (DF) [tos 0x10]
10:20:11.636840 < 194.190.166.31.ssh > 172.16.42.57.1023: P 31140:31344(204) ack 655 win 32616 <nop,nop,timestamp 121274962 8829928> (DF) [tos 0x10]
10:20:11.706843 < 194.190.166.31.ssh > 172.16.42.57.1023: P 31344:31548(204) ack 655 win 32616 <nop,nop,timestamp 121274963 8829935> (DF) [tos 0x10]
10:20:11.766854 < 194.190.166.31.ssh > 172.16.42.57.1023: P 31548:31752(204) ack 655 win 32616 <nop,nop,timestamp 121274963 8829935> (DF) [tos 0x10]
10:20:11.866832 < 194.190.166.31.ssh > 172.16.42.57.1023: P 31752:31956(204) ack 655 win 32616 <nop,nop,timestamp 121274964 8829939> (DF) [tos 0x10]
10:20:11.926839 < 194.190.166.31.ssh > 172.16.42.57.1023: P 31956:32160(204) ack 655 win 32616 <nop,nop,timestamp 121274964 8829939> (DF) [tos 0x10]
10:20:11.996837 < 194.190.166.31.ssh > 172.16.42.57.1023: P 32160:32364(204) ack 655 win 32616 <nop,nop,timestamp 121274984 8829949> (DF) [tos 0x10]
10:20:12.066835 < 194.190.166.31.ssh > 172.16.42.57.1023: P 32364:32568(204) ack 655 win 32616 <nop,nop,timestamp 121274984 8829949> (DF) [tos 0x10]
10:20:12.126850 < 194.190.166.31.ssh > 172.16.42.57.1023: P 32568:32772(204) ack 655 win 32616 <nop,nop,timestamp 121274985 8829956> (DF) [tos 0x10]
10:20:12.216832 < 194.190.166.31.ssh > 172.16.42.57.1023: P 32772:32976(204) ack 655 win 32616 <nop,nop,timestamp 121274985 8829956> (DF) [tos 0x10]
10:20:12.286854 < 194.190.166.31.ssh > 172.16.42.57.1023: P 32976:33180(204) ack 655 win 32616 <nop,nop,timestamp 121274986 8829962> (DF) [tos 0x10]
10:20:12.356846 < 194.190.166.31.ssh > 172.16.42.57.1023: P 33180:33384(204) ack 655 win 32616 <nop,nop,timestamp 121274986 8829962> (DF) [tos 0x10]
10:20:12.426838 < 194.190.166.31.ssh > 172.16.42.57.1023: P 33384:33588(204) ack 655 win 32616 <nop,nop,timestamp 121275007 8829969> (DF) [tos 0x10]
10:20:12.516835 < 194.190.166.31.ssh > 172.16.42.57.1023: P 33588:33792(204) ack 655 win 32616 <nop,nop,timestamp 121275007 8829969> (DF) [tos 0x10]
10:20:12.576830 < 194.190.166.31.ssh > 172.16.42.57.1023: P 33792:33996(204) ack 655 win 32616 <nop,nop,timestamp 121275008 8829976> (DF) [tos 0x10]
10:20:12.646843 < 194.190.166.31.ssh > 172.16.42.57.1023: P 33996:34200(204) ack 655 win 32616 <nop,nop,timestamp 121275008 8829976> (DF) [tos 0x10]
10:20:12.706842 < 194.190.166.31.ssh > 172.16.42.57.1023: P 34200:34404(204) ack 655 win 32616 <nop,nop,timestamp 121275009 8829982> (DF) [tos 0x10]
10:20:12.776850 < 194.190.166.31.ssh > 172.16.42.57.1023: P 34404:34608(204) ack 655 win 32616 <nop,nop,timestamp 121275009 8829982> (DF) [tos 0x10]
10:20:12.846842 < 194.190.166.31.ssh > 172.16.42.57.1023: P 34608:34812(204) ack 655 win 32616 <nop,nop,timestamp 121275029 8829990> (DF) [tos 0x10]
10:20:12.936834 < 194.190.166.31.ssh > 172.16.42.57.1023: P 34812:35016(204) ack 655 win 32616 <nop,nop,timestamp 121275030 8829999> (DF) [tos 0x10]
10:20:13.006840 < 194.190.166.31.ssh > 172.16.42.57.1023: P 35016:35220(204) ack 655 win 32616 <nop,nop,timestamp 121275031 8830006> (DF) [tos 0x10]
10:20:13.046850 < 194.190.166.31.ssh > 172.16.42.57.1023: P 35220:35424(204) ack 655 win 32616 <nop,nop,timestamp 121275032 8830012> (DF) [tos 0x10]
10:20:21.376855 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121275972 8830012> (DF) [tos 0x10]
And from here 194.190.166.31 retransmits until timeout:
10:20:40.146846 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121277852 8830012> (DF) [tos 0x10]
10:21:17.746854 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121281612 8830012> (DF) [tos 0x10]
10:22:32.956845 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121289132 8830012> (DF) [tos 0x10]
10:24:32.966837 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121301132 8830012> (DF) [tos 0x10]
10:26:32.986843 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121313132 8830012> (DF) [tos 0x10]
10:28:32.966854 < 194.190.166.31.ssh > 172.16.42.57.1023: P 30120:30324(204) ack 655 win 32616 <nop,nop,timestamp 121325132 8830012> (DF) [tos 0x10]
--
Eugene Berdnikov
next prev parent reply other threads:[~2001-04-11 10:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-09 14:43 Bug report: tcp staled when send-q != 0, timers == 0 Eugene B. Berdnikov
2001-04-10 17:38 ` kuznet
2001-04-10 21:19 ` Eugene B. Berdnikov
2001-04-11 10:16 ` Eugene B. Berdnikov [this message]
2001-04-11 16:56 ` kuznet
2001-04-11 18:35 ` Eugene B. Berdnikov
2001-04-11 19:04 ` kuznet
2001-04-11 19:28 ` Eugene B. Berdnikov
2001-04-11 19:37 ` kuznet
2001-04-11 16:35 ` kuznet
2001-04-11 18:50 ` Eugene B. Berdnikov
2001-04-11 19:09 ` kuznet
2001-04-11 19:18 ` Eugene B. Berdnikov
2001-04-13 8:54 ` Eugene B. Berdnikov
[not found] ` <200104181928.XAA04912@ms2.inr.ac.ru>
2001-04-21 15:45 ` Eugene B. Berdnikov
2001-04-21 17:02 ` kuznet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010411141645.B12573@elf.ihep.su \
--to=berd@elf.ihep.su \
--cc=davem@redhat.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox