From: Paul Mackerras <paulus@cs.anu.edu.au>
To: rrschulz@cris.com
Cc: linuxppc-user@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: Inbound TCP Circuits over PPP Stall; MTUs and Kppp
Date: Mon, 27 Sep 1999 10:14:35 +1000 [thread overview]
Message-ID: <199909270014.KAA25683@tango.anu.edu.au> (raw)
In-Reply-To: <v04210101b4132312764f@[206.173.234.57]> (message from Randall R Schulz on Sat, 25 Sep 1999 18:49:14 -0700)
Randall R Schulz <rrschulz@cris.com> wrote:
> By using tcpdump, I have discovered what seems to be a relevant fact:
> When the stream stalls, the sending side (always the remote) is
> resending the same range of bytes (sequence numbers) over and over
> again with an inter-packet arrival time that increases gradually
> until it reaches about two minutes where it holds until one side or
> the other gives up and closes the stream. Each such packet has the
> PUSH flag set and elicits an ACK from my system, but for whatever
> reason, the remote just keeps sending repetitions of a packet
> containing the same range of sequence numbers (with a total of 1448
> data bytes each).
This sounds like the remote system isn't getting the ACKs (or they are
getting corrupted). Try putting the `novj' option in your ~/.ppprc
file and see if that makes any difference.
> I have captured the tcpdump output from one of these "sessions"
> (beginning when I clicked a FTP URL link in Navigator through until I
> cancelled the stalled transfer after several repetitions at the
> two-minute inter-packet arrival time. There are 140 lines of tcpdump
> output. If anybody can make use of this in diagnosing the problem,
> I'd be happy to send it...
I would be interested to see it.
> This problem is easily repeated,
Hopefully we can track it down then.
> I'd like to try changing my PPP MTU from 1500 to 1514, but I don't
> know where to control it under kppp and the documentation doesn't
> mention it.
Try making yourself a ~/.ppprc file containing the line `mru 1514'.
In fact the MTU is determined by the MRU (max receive unit) that the
peer asks for so you can't directly control it except to give a
maximum value with the mtu option.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-09-27 0:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-26 1:49 Inbound TCP Circuits over PPP Stall; MTUs and Kppp Randall R Schulz
1999-09-26 6:38 ` Michel Lanners
1999-09-26 21:19 ` Randall R Schulz
1999-09-27 7:07 ` Geert Uytterhoeven
1999-09-27 0:14 ` Paul Mackerras [this message]
1999-09-27 16:35 ` Randall R Schulz
1999-09-27 19:57 ` Michel Lanners
1999-09-28 15:58 ` Lou Langholtz
1999-09-28 16:02 ` Geert Uytterhoeven
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=199909270014.KAA25683@tango.anu.edu.au \
--to=paulus@cs.anu.edu.au \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=linuxppc-user@lists.linuxppc.org \
--cc=rrschulz@cris.com \
/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;
as well as URLs for NNTP newsgroup(s).