Re: v3.1.36: NO ACK with TCP/IP???

Brian (
Tue, 13 May 1997 08:40:11 +0000

I have noticed that on some ISP's terminal servers you must setserial
to 38400. 57600 and 115200 do not allow PPP negotiation.

Date: Sun, 11 May 1997 01:14:30 -0700 (PDT)
From: Alex Belits <>
Reply-to: Alex Belits <>
To: Meino Christian Cramer <>
Subject: Re: v3.1.36: NO ACK with TCP/IP???

On Sun, 11 May 1997, Meino Christian Cramer wrote:

> There is a problem with TCP/IP (or ppp):
> Everytime I connect to
> (and some other sites...) the connection
> and login itsself works fine.
> But any attempt to transfer data (even "ls")
> fails. The modem shows some transfers, then
> the transfer stops. Nothing more happens.
> The line is dead.
> As mentioned by a "local guru" this symptom
> is caused by the "sliding window protocoll".
> His explanation:
> xcf sends some packages ONLY to wait
> for an ACK every time. Then it stops
> (after sending the bundle of packages) and
> waits for an ACK. Meanwhile, the receiving-
> window size on the other end is not "filled"
> completely and the receiver waits for more
> data to send an ACK after "filling his window".
> Now two sites are waiting for each other, nothing
> more happens.
> After some time the sender closes the connection
> because there is now ACK.
> I have played around with different MTU/MRU values
> but nothing works.

I'm not sure, what it can be, but non-working flow control or huge
buffers in modem, can cause ACKs to be lost. The transfers still are
supposed to be re-tried, but maybe, modem has its own opinion about what
is the condition (buffer filling and/or timeout) for sending small
packets, as opposed to large ones that contain data, and all timeouts
will be exceeded before it will do that. To test this, try to create some
additional unrelated traffic between your box and anything behind PPP
connection (say, ping the other end of PPP line). If that fixes the
problem, modem configuration will be the first thing to check -- ping
doesn't interfere with TCP.

Misconfigured flow control can cause other kinds of weirdness,
especially in situation where at least one end of connection uses xon/xoff
(or is set to use xon-xoff while other end has no idea about it), and
asyncmap does not exclude xon and xoff. Some modems just have habit
dropping the connection or hanging for unknown reasons, so if such "line
is dead" situation happened it may be a good idea to check, if the carrier
is up, pppd process is running, interface is configured and up (by
ifconfig), and ping works to at least other end of the line. If lockup
happens and ping stops working, modem is hung, and unless it's a flow
control, the best fix is to replace it. If modem just drops connection
randomly, cron job can be configured to bring it up again, although
any decent hardware shouldn't do that unless the phone line is bad.