linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/

  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).