Messages in this thread | | | From | "Brian" <> | Date | Tue, 13 May 1997 08:40:11 +0000 | Subject | Re: v3.1.36: NO ACK with TCP/IP??? |
| |
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 <abelits@phobos.illtel.denver.co.us> Reply-to: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Meino Christian Cramer <root@solfire.ludwigsburg.netsurf.de> Cc: linux-kernel@vger.rutgers.edu, linux-ppp@vger.rutgers.edu 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 ftp.xcf.berkeley.edu > (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.
-- Alex
bbaird@mail.win.org netsomni@fastrans.net
| |