Bug 2986 - PPP Hangs while sending data w/latest kernels 2.2.2+
PPP Hangs while sending data w/latest kernels 2.2.2+
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alan Cox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-23 12:54 EDT by gandalf
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-11-30 04:40:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description gandalf 1999-05-23 12:54:50 EDT
Using the following:
Kernel 2.2.5 & 2.2.9
PPPd client 2.3.7 (Experience same problem in 2.3.8)
/etc/ppp/options: lock mru 552 mtu 552 modem defaultroute
noipdefault crtscts /dev/modem 115200 :

PPP hangs when sending bursts of data out From localhost,
not when receiving data To localhost. The entire ppp0
interface simply hangs, however the modem is still connected
and appears Idle on the remote machine. Pinging or anything
no longer works through the interface and there is no way to
restart it except to kill pppd, ifconfig ppp0 down, and try
again. I've talked over with a friend who has an ethernet
card and was able to reproduce the problem on eth0 with a
400 MHz machine and an unbelievable burst speed. It simply
hangs up the interface, therefore I believe it is something
with the kernel. The last time I tried PPP successfully was
with 2.1.50-58 kernels last summer or so. None of my options
have changed since. PPP works fine for me as long as I do
not send anything over 40k at a time over the interface,
however I can download as much as I want and nothing will
happen. I am believing this is something to do with
overflowing a buffer for the interface, and not the options
specified in /etc/ppp/options. To clarify, I am not using
the automatic PPP scripts that comes with RedHat 6.0, rather
instead just doing a direct interface with the pppd program
as I always have.

Thank you for your time, and if possible speedy response.
Comment 1 tbarraza 1999-05-26 22:55:59 EDT
I've been experiencing similar problems, and have since removed
the mru & mtu statements from my /etc/ppp/options file (actually,
I commented them out), and my modem has not hung up since. I also
used my same scripts in 5.2 without any problems whatsoever.

------- Additional Comments From   09/23/99 11:56 -------
I am having the same problem; however, removing the mru and mtu
options does not help.  I am able to get a PPP connection, ping, even
ftp and some web browsing; however, when i attempt to telnet, i
experience a long wait before getting the message "Host name lookup
failure" from telnet.  After this point, i can no longer ping, ftp,
browse etc.  This makes the OS basically unusable for me since a PPP
connection is central to what i need to do.

------- Additional Comments From   09/29/99 13:31 -------
I was able to solve my ppp problems by disabling vj header compression
with the command line option 'novj' to pppd.
Comment 2 Alex 1999-11-30 04:40:59 EST
I think I've come across a similer thing as described here. Appologies for the
long CC but this is the information that has been on the linux.dev.ppp list.

Quoted from usenet:

Followup Information:

Having managed to recreate it again I have the the following "facts" to add to
the confusion.

1. It doesn't seem to be a magic number in terms of data ( it has variously
failed after 80Mb, 100Mb and 130Mb of downstream data). The number of frames
varies quite a bit as well.

2. As far as I can tell its not time related either (today was 10:30 until
19:00ish, about 8 1/2 hours). I shall try and time it exactly next week - its
hard to tell as the logs show nothing, its just when your client machines start
failing to connect you know its gone wrong.

3. The line is still up. The modem still shows CD, and pinging the remote end
of the PPP link does result in the modem SD light flashing (although there is
no response).

4. The routing table is fine. There is no change to the routing table once the
link has achieved this locked up state.

5. I am assuming the serial line is OK as I have seen things tranmitted since
the lockup (see 3).

I'm really confused about this one, if its an ISP problem I would expect the
link to be dumped and the ppp.log show some sort of shutdown process. The link
is never idle long enough (i have some slow repeating pings in anycase).

Quoted Original Message :

I've been  experiencing problems with my dialup link. Once a week my machine
goes online for 24 hours (taking advantage of a telco offer) and starts a
mass download activity. However after a while (about 130Mb of download) the
ppp link seems to lock up. pppd itself is fine but the outside network
becomes unreachable. I've tried doing a sneding SIGUSR2 to pppd to
renegotiate compression and have noted the lights on the modem do not flash.
The only way to get out is to kill the dialup and redial in. I would like to
track the source of the problem and have so far come up with these possible
candiates:

pppd, the kernel ppp code, the serial driver, the TCP/IP stack itself

I don't think its the TCP/IP stack itself as all this data is being
masquraded  to other machines and if this is so I would of expected the whole
machine to become invisible to the network once it had passed 130Mb, which it
doesn't.

Does anyone have any suggestions on how I could diagnose the dialup link? For
example is there anyway to get ppp to logoff and restart without killing the
serial link?

Details: Dell 486/66 running Linux 2.2.12 (also tried other 2.2 kernels)
built ontop a minimal RedHat 5.2 base. Generic V.90 Modem via COM1 ppp 2.3.9
wvdial 1.4 as dialer IP Masquearding enabled (download done from Win98
machine)
Comment 3 Alan Cox 2000-08-05 10:23:40 EDT
If this is still occuring in 6.2 please re-open it

Note You need to log in before you can comment on or make changes to this bug.