PPP/modem connection dies when uploading

I've had problems off and on for over a year when uploading large
files from my old Linux laptop through a modem and my ISP (Internet
America). I can connect to the Internet and do hours of surfing or
downloading without any particular problems, but when I try to upload
stuff, the connection quickly dies. In particular, now when I try
to "cvs up" to SourceForge after a change which touches most lines
of >5 megabytes of code, the link dies after at most a few hundred
kilobytes. For this upload I can't think of any workaround less
painful than just fixing the network problem, so I've tried to get
serious about fixing it, but I haven't made any progress.

I have Googled for keys like "pppd echo-requests linux", and tried
much fiddling with "/etc/ppp/options":
* Set "lcp-echo-failure 4" and "lcp-echo-interval 65535" to
discourage the system from asking for echoes. Unfortunately,
that seems just to shift the symptoms to quietly locking up,
in a state where I can repeatedly run "ifconfig" and see that
the ppp0 connection is only very occasionally sending a packet
and never receiving one.
* Set "mtu 1492" or smaller.
* Set "mru 1500" or smaller.
* Set various values of "asyncmap", including 0 and 0xa0000 and none.
* Set various values of "escape", including none.
The current state of my /etc/ppp/options file, from
# egrep -v '^#|^ *$' /etc/ppp/options
is
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
mtu 900
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx

I have also fiddled with the chat script for the modem; until
yesterday, it was using ATZ for initialization, but is now doing AT&F
(dunno whether that's legal syntax, couldn't find docs on the web) and
AT&F0. Alas, I can't figure out what kind of modem it is, just some
vaguely generic PCMCIA card; I've lost any documentation I might have
had for it, and the only information on its case which looks as though
it might identify it is P/N: CPD56K-W, with no manufacturer
information, unless perhaps "PC Card" is the name of the manufacturer.
(If I learn that it's a good bet that the modem is the problem and I
learn a reliable replacement card, I'd be happy to switch.)

There are some things about the /var/log/syslog output that I
don't understand. Especially, I found on a Cisco FAQ describing
a similar problem
A: It sounds like this might be a Maximum Receive Unit (MRU) problem.
The MRU for PPP is 1500 bytes, as specified in RFC1661. If another
one
of your routers or PPP clients is sending packets larger than this,
the 900i or any other Compatible Systems router will not accept them.
If you're running async, make sure you're using Hardware Flow Control
for the WAN port.
I can see from the log that mru=1524 is being negotiated, which seems
odd. Still, even if the FAQ is correct and my ISP uses equipment like
this (dunno about either of those "if"s), I'd think that the low MTU
setting on my end (currently 900) would keep my box from sending any
too-big packets.

I think my debugging of this problem may be complicated by the
Internet America folks using different settings on different machines
behind the same dialin number. (Or possibly there's some race
condition for which end speaks first in negotiation?) In particular,
it seems as though when I use "asyncmap 0" in my /etc/ppp/options,
then read the /var/log/syslog output, in some sessions 0xa0000 is
requested
by the box at the IA end, but in other sessions 0xa0000 is never
mentioned
and 0x0 is OK with everyone.

The rest of this message is the /var/log/syslog output from
a PPP session created by
# pon
and hung by
% cvs up
with the /etc/ppp/options given above.
Jul 12 10:25:46 d10 pppd[18023]: pppd 2.4.1 started by root, uid 0
Jul 12 10:25:47 d10 chat[18024]: abort on (BUSY)
Jul 12 10:25:47 d10 chat[18024]: abort on (NO CARRIER)
Jul 12 10:25:47 d10 chat[18024]: abort on (VOICE)
Jul 12 10:25:47 d10 chat[18024]: abort on (NO DIALTONE)
Jul 12 10:25:47 d10 chat[18024]: abort on (NO DIAL TONE)
Jul 12 10:25:47 d10 chat[18024]: abort on (NO ANSWER)
Jul 12 10:25:47 d10 chat[18024]: abort on (DELAYED)
Jul 12 10:25:47 d10 chat[18024]: timeout set to 5 seconds
Jul 12 10:25:47 d10 chat[18024]: expect (OK)
Jul 12 10:25:47 d10 chat[18024]: ^M
Jul 12 10:25:47 d10 chat[18024]: OK
Jul 12 10:25:47 d10 chat[18024]: -- got it
Jul 12 10:25:47 d10 chat[18024]: send (AT&F^M)
Jul 12 10:25:47 d10 chat[18024]: timeout set to 5 seconds
Jul 12 10:25:47 d10 chat[18024]: expect (OK)
Jul 12 10:25:47 d10 chat[18024]: ^M
Jul 12 10:25:47 d10 chat[18024]: AT&F^M^M
Jul 12 10:25:47 d10 chat[18024]: OK
Jul 12 10:25:47 d10 chat[18024]: -- got it
Jul 12 10:25:47 d10 chat[18024]: send (AT&F0^M)
Jul 12 10:25:47 d10 chat[18024]: timeout set to 5 seconds
Jul 12 10:25:47 d10 chat[18024]: expect (OK)
Jul 12 10:25:47 d10 chat[18024]: ^M
Jul 12 10:25:48 d10 chat[18024]: AT&F0^M^M
Jul 12 10:25:48 d10 chat[18024]: OK
Jul 12 10:25:48 d10 chat[18024]: -- got it
Jul 12 10:25:48 d10 chat[18024]: send (ATDT9728650073^M)
Jul 12 10:25:48 d10 chat[18024]: timeout set to 30 seconds
Jul 12 10:25:48 d10 chat[18024]: expect (CONNECT)
Jul 12 10:25:48 d10 chat[18024]: ^M
Jul 12 10:26:18 d10 chat[18024]: alarm
Jul 12 10:26:18 d10 chat[18024]: Failed
Jul 12 10:26:18 d10 pppd[18023]: Connect script failed
Jul 12 10:26:50 d10 chat[18025]: abort on (BUSY)
Jul 12 10:26:50 d10 chat[18025]: abort on (NO CARRIER)
Jul 12 10:26:50 d10 chat[18025]: abort on (VOICE)
Jul 12 10:26:50 d10 chat[18025]: abort on (NO DIALTONE)
Jul 12 10:26:50 d10 chat[18025]: abort on (NO DIAL TONE)
Jul 12 10:26:50 d10 chat[18025]: abort on (NO ANSWER)
Jul 12 10:26:50 d10 chat[18025]: abort on (DELAYED)
Jul 12 10:26:50 d10 chat[18025]: timeout set to 5 seconds
Jul 12 10:26:50 d10 chat[18025]: expect (OK)
Jul 12 10:26:55 d10 chat[18025]: alarm
Jul 12 10:26:55 d10 chat[18025]: send (AT^M)
Jul 12 10:26:55 d10 chat[18025]: expect (OK)
Jul 12 10:26:55 d10 chat[18025]: AT^M^M
Jul 12 10:26:55 d10 chat[18025]: OK
Jul 12 10:26:55 d10 chat[18025]: -- got it
Jul 12 10:26:55 d10 chat[18025]: send (AT&F^M)
Jul 12 10:26:55 d10 chat[18025]: timeout set to 5 seconds
Jul 12 10:26:55 d10 chat[18025]: expect (OK)
Jul 12 10:26:55 d10 chat[18025]: ^M
Jul 12 10:26:55 d10 chat[18025]: AT&F^M^M
Jul 12 10:26:55 d10 chat[18025]: OK
Jul 12 10:26:55 d10 chat[18025]: -- got it
Jul 12 10:26:55 d10 chat[18025]: send (AT&F0^M)
Jul 12 10:26:55 d10 chat[18025]: timeout set to 5 seconds
Jul 12 10:26:55 d10 chat[18025]: expect (OK)
Jul 12 10:26:55 d10 chat[18025]: ^M
Jul 12 10:26:55 d10 chat[18025]: AT&F0^M^M
Jul 12 10:26:55 d10 chat[18025]: OK
Jul 12 10:26:55 d10 chat[18025]: -- got it
Jul 12 10:26:55 d10 chat[18025]: send (ATDT9728650073^M)
Jul 12 10:26:56 d10 chat[18025]: timeout set to 30 seconds
Jul 12 10:26:56 d10 chat[18025]: expect (CONNECT)
Jul 12 10:26:56 d10 chat[18025]: ^M
Jul 12 10:27:23 d10 chat[18025]: ATDT9728650073^M^M
Jul 12 10:27:23 d10 chat[18025]: CONNECT
Jul 12 10:27:23 d10 chat[18025]: -- got it
Jul 12 10:27:23 d10 chat[18025]: send (\d)
Jul 12 10:27:24 d10 pppd[18023]: Serial connection established.
Jul 12 10:27:24 d10 pppd[18023]: using channel 76
Jul 12 10:27:24 d10 pppd[18023]: Using interface ppp0
Jul 12 10:27:24 d10 pppd[18023]: Connect: ppp0 <--> /dev/ttyS0
Jul 12 10:27:25 d10 pppd[18023]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x61e33055> <pcomp> <accomp>]
Jul 12 10:27:26 d10 pppd[18023]: rcvd [LCP ConfReq id=0x1 < 00 04 00
00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <mrru
1524> <endpoint [MAC:00:d0:52:01:3e:71]>]
Jul 12 10:27:26 d10 pppd[18023]: sent [LCP ConfRej id=0x1 < 00 04 00
00> <mrru 1524>]
Jul 12 10:27:26 d10 pppd[18023]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x61e33055> <pcomp> <accomp>]
Jul 12 10:27:28 d10 pppd[18023]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x61e33055> <pcomp> <accomp>]
Jul 12 10:27:29 d10 pppd[18023]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:d0:52:01:3e:71]>]
Jul 12 10:27:29 d10 pppd[18023]: sent [LCP ConfAck id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:d0:52:01:3e:71]>]
Jul 12 10:27:29 d10 pppd[18023]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:d0:52:01:3e:71]>]
Jul 12 10:27:29 d10 pppd[18023]: sent [LCP ConfAck id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp> <endpoint
[MAC:00:d0:52:01:3e:71]>]
Jul 12 10:27:29 d10 pppd[18023]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x61e33055> <pcomp> <accomp>]
Jul 12 10:27:29 d10 pppd[18023]: sent [LCP EchoReq id=0x0
magic=0x61e33055]
Jul 12 10:27:29 d10 pppd[18023]: sent [PAP AuthReq id=0x1
user="a0019176" password=<hidden>]
Jul 12 10:27:31 d10 pppd[18023]: rcvd [LCP EchoRep id=0x0 magic=0x0]
Jul 12 10:27:31 d10 pppd[18023]: rcvd [PAP AuthAck id=0x1 ""]
Jul 12 10:27:31 d10 pppd[18023]: kernel does not support PPP filtering
Jul 12 10:27:31 d10 pppd[18023]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Jul 12 10:27:31 d10 pppd[18023]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Jul 12 10:27:31 d10 pppd[18023]: rcvd [IPCP ConfReq id=0x1 <compress VJ
0f 01> <addr 66.90.132.23>]
Jul 12 10:27:31 d10 pppd[18023]: sent [IPCP ConfAck id=0x1 <compress VJ
0f 01> <addr 66.90.132.23>]
Jul 12 10:27:32 d10 pppd[18023]: rcvd [IPCP ConfReq id=0x1 <compress VJ
0f 01> <addr 66.90.132.23>]
Jul 12 10:27:32 d10 pppd[18023]: sent [IPCP ConfAck id=0x1 <compress VJ
0f 01> <addr 66.90.132.23>]
Jul 12 10:27:34 d10 pppd[18023]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Jul 12 10:27:34 d10 pppd[18023]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Jul 12 10:27:37 d10 pppd[18023]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Jul 12 10:27:37 d10 pppd[18023]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Jul 12 10:27:40 d10 pppd[18023]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Jul 12 10:27:40 d10 pppd[18023]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [IPCP ConfNak id=0x1 <addr
207.136.49.243>]
Jul 12 10:27:40 d10 pppd[18023]: sent [IPCP ConfReq id=0x2 <addr
207.136.49.243> <compress VJ 0f 01>]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [LCP ProtRej id=0x3 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [LCP ProtRej id=0x4 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [IPCP ConfNak id=0x1 <addr
207.136.49.243>]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [IPCP ConfNak id=0x1 <addr
207.136.49.243>]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [LCP ProtRej id=0x5 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [LCP ProtRej id=0x6 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jul 12 10:27:40 d10 pppd[18023]: rcvd [IPCP ConfNak id=0x1 <addr
207.136.49.243>]
Jul 12 10:27:42 d10 pppd[18023]: rcvd [IPCP ConfAck id=0x2 <addr
207.136.49.243> <compress VJ 0f 01>]
Jul 12 10:27:42 d10 pppd[18023]: Cannot determine ethernet address for
proxy ARP
Jul 12 10:27:42 d10 pppd[18023]: local IP address 207.136.49.243
Jul 12 10:27:42 d10 pppd[18023]: remote IP address 66.90.132.23
Jul 12 10:27:42 d10 pppd[18023]: Script /etc/ppp/ip-up started (pid
18029)
Jul 12 10:27:47 d10 pppd[18023]: Script /etc/ppp/ip-up finished (pid
18029), status = 0x0
Jul 12 10:27:59 d10 pppd[18023]: sent [LCP EchoReq id=0x1
magic=0x61e33055]
Jul 12 10:27:59 d10 pppd[18023]: rcvd [LCP EchoRep id=0x1 magic=0x0]
Jul 12 10:28:29 d10 pppd[18023]: sent [LCP EchoReq id=0x2
magic=0x61e33055]
Jul 12 10:28:29 d10 pppd[18023]: rcvd [LCP EchoRep id=0x2 magic=0x0]
Jul 12 10:28:59 d10 pppd[18023]: sent [LCP EchoReq id=0x3
magic=0x61e33055]
Jul 12 10:29:01 d10 pppd[18023]: rcvd [LCP EchoRep id=0x3 magic=0x0]
Jul 12 10:29:29 d10 pppd[18023]: sent [LCP EchoReq id=0x4
magic=0x61e33055]
Jul 12 10:29:32 d10 pppd[18023]: rcvd [LCP EchoRep id=0x4 magic=0x0]
Jul 12 10:29:59 d10 pppd[18023]: sent [LCP EchoReq id=0x5
magic=0x61e33055]
Jul 12 10:30:29 d10 pppd[18023]: sent [LCP EchoReq id=0x6
magic=0x61e33055]
Jul 12 10:30:59 d10 pppd[18023]: sent [LCP EchoReq id=0x7
magic=0x61e33055]
Jul 12 10:31:29 d10 pppd[18023]: sent [LCP EchoReq id=0x8
magic=0x61e33055]
Jul 12 10:31:59 d10 pppd[18023]: No response to 4 echo-requests
Jul 12 10:31:59 d10 pppd[18023]: Serial link appears to be
disconnected.
Jul 12 10:31:59 d10 pppd[18023]: Script /etc/ppp/ip-down started (pid
18125)
Jul 12 10:31:59 d10 pppd[18023]: sent [LCP TermReq id=0x2 "Peer not
responding"]
Jul 12 10:31:59 d10 pppd[18023]: Script /etc/ppp/ip-down finished (pid
18125), status = 0x0
Jul 12 10:32:02 d10 pppd[18023]: sent [LCP TermReq id=0x3 "Peer not
responding"]
Jul 12 10:32:05 d10 pppd[18023]: Connection terminated.
Jul 12 10:32:05 d10 pppd[18023]: Connect time 4.6 minutes.
Jul 12 10:32:05 d10 pppd[18023]: Sent 182374 bytes, received 14214
bytes.
Jul 12 10:33:07 d10 pppd[18023]: Hangup (SIGHUP)
Jul 12 10:33:07 d10 pppd[18023]: ioctl(TIOCSETD, N_TTY): Interrupted
system call

On 12 Jul 2005 08:56:29 -0700, (E-Mail Removed)
<(E-Mail Removed)> wrote:
>
> I have Googled for keys like "pppd echo-requests linux", and tried
> much fiddling with "/etc/ppp/options":
> * Set "lcp-echo-failure 4" and "lcp-echo-interval 65535" to
> discourage the system from asking for echoes. Unfortunately,
> that seems just to shift the symptoms to quietly locking up,
> in a state where I can repeatedly run "ifconfig" and see that
> the ppp0 connection is only very occasionally sending a packet
> and never receiving one.

Set a shorter lcp-echo-interval, like 30 seconds. The echoes are your
friend; if you don't get echoes, your connection is dead even if your
modem thinks you are still connected. You may need to disable call
waiting.


--
Tonight you will pay the wages of sin; Don't forget to leave a tip.

Bill Marcum wrote:
> On 12 Jul 2005 08:56:29 -0700, (E-Mail Removed)
> <(E-Mail Removed)> wrote:
> >
> > I have Googled for keys like "pppd echo-requests linux", and tried
> > much fiddling with "/etc/ppp/options":
> > * Set "lcp-echo-failure 4" and "lcp-echo-interval 65535" to
> > discourage the system from asking for echoes. Unfortunately,
> > that seems just to shift the symptoms to quietly locking up,
> > in a state where I can repeatedly run "ifconfig" and see that
> > the ppp0 connection is only very occasionally sending a packet
> > and never receiving one.
>
> Set a shorter lcp-echo-interval, like 30 seconds. The echoes are your
> friend; if you don't get echoes, your connection is dead even if your
> modem thinks you are still connected. You may need to disable call
> waiting.

Yes, that makes sense; and in fact I had already fallen back to using
lcp-echo-interval 30, as per my ppp/options file. My experimentation
with
suppressing lcp-echo-interval was motivated when Google led me to

http://www.linuxdevcenter.com/pub/a/...lular.html?pag
e=last&x-order=date
which had a code snippet
# Use the next two lines if you receive the dreaded messages:
#
# No response to n echo-requests
# Serial link appears to be disconnected.
# Connection terminated.
#
lcp-echo-failure 4
lcp-echo-interval 65535
which seemed to encourage this suppression for some perhaps-unusual
cases perhaps only in wireless links; I tried it in "why not? [perhaps
workaround for pppd bug?]" spirit, gave it up when it didn't help,
and mentioned it among things I tried only for completeness.

Thank you.

(E-Mail Removed) wrote:
> I've had problems off and on for over a year when uploading large
> files from my old Linux laptop through a modem and my ISP (Internet
> America). I can connect to the Internet and do hours of surfing or
> downloading without any particular problems, but when I try to upload
> stuff, the connection quickly dies. In particular, now when I try
> to "cvs up" to SourceForge after a change which touches most lines
> of >5 megabytes of code, the link dies after at most a few hundred
> kilobytes. For this upload I can't think of any workaround less
> painful than just fixing the network problem, so I've tried to get
> serious about fixing it, but I haven't made any progress.

Google:
PCMCIA modem upload problem

http://lists.naos.co.nz/pipermail/we...ne/012661.html

I'm not sure about quality of the answers but it's interesting reading.

For many modems adding "ATW1s95=47 OK" after "AT&F OK" in the chat
script will provide modem-to-ISP connection speeds as well as modem
protocols negotiated. Those may help lead to a solution if the link
above is not productive. The outputs of "stty -a -F /dev/ttyS0" and
"setserial -a /dev/ttyS0" *during a connection* could also help.

Based on your post the problem does sound to me like a buffer overflow
somewhere. BTW, adding the pppd options noccp and nomp would prevent
useless negotiations and a cleaner log.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */

I seem to have fixed my problem. My ISP (Internet America) wants PPP
clients to be hand-configured with "mru 552" and "mtu 552". These
settings are given in their web page
<http://support.airmail.net/connect/analog/cfgunixppp.php>; I don't
think that web page existed years ago when I initially set up my
connection, but I was able to surf to it from the boilerplate in the
"we have opened a trouble ticket" automated form letter that I was
sent when I sent email to their support department asking about the
problem. After switching to these recommended settings the
unreliability of my connection was reduced from unspeakably pathetic
(failing reliably after 100k bytes or so) to merely sad (20% infant
mortality, then mean time to failure 2M bytes or so). My big CVS
commit is done now, so my immediate needs were met despite sadness. In
the longer term, probably I want to find a less flaky ISP and perhaps
also switch to DSL and wireless, dropping my old phone modem in the
rubbish with the floppy disks and serial connections and whatnot.

The cfgunixppp.php page doesn't give any explanation of why the
settings are
needed, and I have no clue why the system doesn't seem to try to
negotiate them in the LCP setup logged in my original message. The
closest thing to a specific explanation I have is the "My PPP users
cannot upload to an FTP site; download works fine" entry in
"Compatible Systems - CSU/DSU and Modem Issues: Frequently Asked
Questions" at
<http://www.cisco.com/en/US/products/hw/routers/ps4081/products_qanda_item09186a0080094734.shtml>.
That's not much of an explanation, though; perhaps the general
explanation is just that key actors along the ISP and router-maker
foodchain choose to be more conservative than in what they accept than
the standard allows, and more liberal in what they send than the
standard allows.:-(

(E-Mail Removed) wrote:
> I seem to have fixed my problem. My ISP (Internet America) wants PPP
> clients to be hand-configured with "mru 552" and "mtu 552". These
> settings are given in their web page
> <http://support.airmail.net/connect/analog/cfgunixppp.php>; I don't

Those simply limit the data in a TCP/IP segment to 512 bytes.
I'd suspect the data reduction from 1460 to 512 helps reduce
the probability that a buffer overflows. Reducing to mtu/mru
296 (256 data bytes) may help reduce it even more. The ISP
may recommend mtu/mru 552 to help get through an old (ancient?)
router that might be somewhere in the path and doesn't use PMTU
discovery (but it's unlikely that IA itself has any such router).

> think that web page existed years ago when I initially set up my
> connection, but I was able to surf to it from the boilerplate in the
> "we have opened a trouble ticket" automated form letter that I was
> sent when I sent email to their support department asking about the
> problem. After switching to these recommended settings the
> unreliability of my connection was reduced from unspeakably pathetic
> (failing reliably after 100k bytes or so) to merely sad (20% infant
> mortality, then mean time to failure 2M bytes or so). My big CVS
> commit is done now, so my immediate needs were met despite sadness. In
> the longer term, probably I want to find a less flaky ISP and perhaps
> also switch to DSL and wireless, dropping my old phone modem in the
> rubbish with the floppy disks and serial connections and whatnot.

If there's buffer overflow on your end then the ISP is not at fault.

> The cfgunixppp.php page doesn't give any explanation of why the
> settings are
> needed, and I have no clue why the system doesn't seem to try to
> negotiate them in the LCP setup logged in my original message. The
> closest thing to a specific explanation I have is the "My PPP users
> cannot upload to an FTP site; download works fine" entry in
> "Compatible Systems - CSU/DSU and Modem Issues: Frequently Asked
> Questions" at
> <http://www.cisco.com/en/US/products/hw/routers/ps4081/products_qanda_item09186a0080094734.shtml>.
> That's not much of an explanation, though; perhaps the general
> explanation is just that key actors along the ISP and router-maker
> foodchain choose to be more conservative than in what they accept than
> the standard allows, and more liberal in what they send than the
> standard allows.:-(

Are you talking about the post there beginning with "I'm an ISP running
Linux 1.2.13?" That's not related to your problem, guaranteed.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* I hear and I forget. I see and I remember. I do and I understand.
--Confucius, 551-479 BC */

(E-Mail Removed) wrote:
> I seem to have fixed my problem. My ISP (Internet America) wants PPP
> clients to be hand-configured with "mru 552" and "mtu 552". These
> settings are given in their web page
> <http://support.airmail.net/connect/analog/cfgunixppp.php>; I don't
> think that web page existed years ago when I initially set up my
> connection, but I was able to surf to it from the boilerplate in the
> "we have opened a trouble ticket" automated form letter that I was
> sent when I sent email to their support department asking about the
> problem. After switching to these recommended settings the
> unreliability of my connection was reduced from unspeakably pathetic
> (failing reliably after 100k bytes or so) to merely sad (20% infant
> mortality, then mean time to failure 2M bytes or so). My big CVS
> commit is done now, so my immediate needs were met despite sadness. In
> the longer term, probably I want to find a less flaky ISP and perhaps
> also switch to DSL and wireless, dropping my old phone modem in the
> rubbish with the floppy disks and serial connections and whatnot.
>
> The cfgunixppp.php page doesn't give any explanation of why the
> settings are
> needed, and I have no clue why the system doesn't seem to try to
> negotiate them in the LCP setup logged in my original message. The
> closest thing to a specific explanation I have is the "My PPP users
> cannot upload to an FTP site; download works fine" entry in
> "Compatible Systems - CSU/DSU and Modem Issues: Frequently Asked
> Questions" at
> <http://www.cisco.com/en/US/products/hw/routers/ps4081/products_qanda_item09186a0080094734.shtml>.
> That's not much of an explanation, though; perhaps the general
> explanation is just that key actors along the ISP and router-maker
> foodchain choose to be more conservative than in what they accept than
> the standard allows, and more liberal in what they send than the
> standard allows.:-(
>

Maybe a clueless ISP killing the ICMP messages needed
to handle tha maximum segment size correctly (Path MTU
Discovery).

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <(E-Mail Removed)> wrote:

> Maybe a clueless ISP killing the ICMP messages needed
> to handle tha maximum segment size correctly (Path MTU
> Discovery).

In the OP's first post he sent 182374 bytes, all likely sent before
trouble developed. That doesn't sound like it's an PMTU Discovery
problem to me.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
/* The signal-to-noise ratio is too low in many [news] groups to make
* them good candidates for archiving.
* --- Mike Moraes, Answers to FAQs about Usenet */

Clifford Kite wrote:
> Tauno Voipio <(E-Mail Removed)> wrote:
>
>
>>Maybe a clueless ISP killing the ICMP messages needed
>>to handle tha maximum segment size correctly (Path MTU
>>Discovery).
>
>
> In the OP's first post he sent 182374 bytes, all likely sent before
> trouble developed. That doesn't sound like it's an PMTU Discovery
> problem to me.
>

He still reported that the trouble disappeared when
the MTU was limited. It can also be a brain-dead PPP
not able to negotiate the link MTU properly.

The diagnosis would need a network trace of the
failed transfer.

I noticed that the Windows TCP does not check whether
the last FIN will get its ACK. This causes hanging
connections if the network loses the last FIN or
its ACK.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <(E-Mail Removed)> wrote:
> Clifford Kite wrote:
>>
>> In the OP's first post he sent 182374 bytes, all likely sent before
>> trouble developed. That doesn't sound like it's an PMTU Discovery
>> problem to me.

> He still reported that the trouble disappeared when
> the MTU was limited. It can also be a brain-dead PPP
> not able to negotiate the link MTU properly.

Actually he didn't say that "the trouble disappeared." Essentially
he said it happened less often.

I saw nothing wrong with the MTU/MRU negotiation in the posted log.
It should have worked fine just as it was.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Speak softly and carry a sucker rod (See man syslogd, footnote to
recommendation 4 under SECURITY THREATS). */