Since upgrading from 6.0 -> 6.1 I've noticed some problems
with pppd. Every time I connect to my ISP it fails on the
first attempt and suceeds on the second. Here is output
Oct 14 23:17:49 ppro ifup-ppp: pppd started for ppp0 on
/dev/modem at 115200
Oct 14 23:17:49 ppro modprobe: can't locate module
Oct 14 23:17:49 ppro kernel: CSLIP: code copyright 1989
Regents of the
University of California
Oct 14 23:17:49 ppro kernel: PPP: version 2.3.7 (demand
Oct 14 23:17:49 ppro kernel: PPP line discipline registered.
Oct 14 23:17:49 ppro kernel: registered device ppp0
Oct 14 23:17:49 ppro pppd: pppd 2.3.10 started by
root, uid 0
Oct 14 23:18:05 ppro PAM_pwdb: (login) session opened
for user eisenhow by
Oct 14 23:18:11 ppro pppd: Serial connection
Oct 14 23:18:11 ppro pppd: Using interface ppp0
Oct 14 23:18:11 ppro pppd: Connect: ppp0 <-->
Oct 14 23:18:12 ppro pppd: Hangup (SIGHUP)
Oct 14 23:18:13 ppro pppd: Connection terminated.
Oct 14 23:18:13 ppro pppd: Hangup (SIGHUP)
Oct 14 23:18:13 ppro pppd: Exit.
Oct 14 23:18:16 ppro ifup-ppp: pppd started for ppp0 on
/dev/modem at 115200
Oct 14 23:18:16 ppro modprobe: can't locate module
Oct 14 23:18:16 ppro pppd: pppd 2.3.10 started by
root, uid 0
Oct 14 23:18:38 ppro pppd: Serial connection
Oct 14 23:18:38 ppro pppd: Using interface ppp0
Oct 14 23:18:38 ppro pppd: Connect: ppp0 <-->
Oct 14 23:18:41 ppro kernel: PPP BSD Compression module
Oct 14 23:18:41 ppro pppd: local IP address
Oct 14 23:18:41 ppro pppd: remote IP address
Oct 14 23:18:41 ppro pppd: primary DNS address
Oct 14 23:18:41 ppro pppd: secondary DNS address
I've blanked out the IP's for privacy but it appears
that pppd is received a SIGHUP, from where I don't know, on
the first attempt.
I've confirmed the problem with another member of
the redhat-list who has had the same problem and similar
messages in his logs.
I notice that ppp has been upgraded from 2.2.7->2.2.10 and
that the patches have been changed (some
updated, one removed). I'm not sure if it is a ppp problem
or a redhat patch problem.
I initially had this problem and also another problem. Whenever I
dialed the modem, it would link up but the network was unusable. THis
was because the dialer wasn't adding the default route for my p-t-p
After I added 'defaultroute' to /etc/ppp/options, the modem connects
on the first dial, and I don't have to manually add the route anymore.
Thanks for the suggestions, but this is not my problem. Perhaps I
wasn't clear. I run /usr/sbin/usernetctl ppp0 up once. It dials my
ISP "talks" for a while, hangs up, and dials again (I have PERSIST=yes
in ifcfg-ppp0, along with DEFROUTE=yes).
After looking further, I'm new to bugzilla, it appears that the bug I
reported is a duplicate of bug #5663 (upgrade to 6.1 causes ppp to
fail first connect attempt ). Is there any new news on this bug Red
I see this too, as do several of my friends. Apparently it's to do
with loading a kernel module too late?
I would suggest the severity is higher than "low". In some places
there is a minimum charge on a call connection, so a wasted call isn't
desirable. Also, a modem connect takes long enough that doubling
connect time is a bad idea!!!
As an aside, the new GUI modem tools are nice but there is not enough
user feedback - e.g. no indication is given that attempt #1 failed. No
indication is given that attempt #2 has started. There is no
distinction between "dialling", "authenticating", "negotiating
options" etc!!!!!! Would you like me to log a separate bug about this?
------- Additional Comments From 11/03/99 03:48 -------
It happens unly when using ifup/usernet/rp3. wvdial setup
works right from the beginning. Also 230400 speed which worked with
6.1 now does not work.
------- Additional Comments From 11/04/99 04:13 -------
I too have the same problems with the ppp link in RH6.1
I think I have narrowed the problem down to either a buggy or broken
When 'ifup ppp0' is executed on the command line the modem dials and
connects correctly and
pppd is initiated. pppd then for some unknown reason to me it gets a
SIGHUP from somewhere
which causes it to hangup the modem and dial again. 99 out of 100
times the 2nd connection
attempt is successful with pppd establishing a link. However, when
configured to start upon
boot the modem never establishes a connection and continually
redials. At $.20(AUS) per
telephone connection its quite an expensive problem!! :-( The other
problem is that the
module char-major-108 cannot be found.
After searching the net for information I was unable to find anything
of any real use.
Although someone has had success down-grading the verison of pppd and
getting that to work.
I have tried but have not had any success as yet. I downloaded
versions 2.3.7 to 2.3.10
from ftp://cs.anu.edu.au/pub/software/ppp and tried each one but the
same problem exists.
Version 2.3.7 & 2.3.8 also generate errors in the messages log
something like 'invalid
command linkname'. I can only assume that versions 2.3.9 and above
have new command line
switches that have not made it into the man pages yet.
After experimenting with the 'ifup-ppp' script I commented out the
exec /sbin/ppp-watch "$@"
This workaround kinda works in that when initiated from the
commandline the modem connects
and a ppp link is extablished 1st go every go. BUT the 'ifdown-ppp'
script does not work as
it relies on ppp-watch to kill pppd. pppd can be sucessfully killed
and the modem
connection hungup by 'kill -s 9 ....'. However, CTRL-Z or CTRL-C is
the only way to get out
of the 'ifup' script once the link is up and it seems to hang the
booting process when ppp0
is configured to start on boot.
From this information does anyone out-therehave any ideas or other
From my experimenting it seems that the problem is either a buggy or
or ifup-ppp script.
Does anyone know how to rewrite the ifup/down-ppp scripts to remove
ppp-watch and still get
it to work from the command line or automatically on boot?
Does anyone have any information on what ppp-watch realy does? as I
have been unable to find
any information on it.
Someone suggested for the 'module char-major-108 cannot be found'
problem to put aliases in
the 'conf.modules' file. Even though this gets rid of the error
messages in the messages
log I'm not convinced that this fixes the original problem.
Again does someone out-there have any ideas or other
Thanks in Advance
and see if it fixes this problem for you.
After upgrading to the rpm ppp-2.3.10-3 ppp is now totally non-
Downgrading to 2.3.10-1 doesn't fix it.
Downgrading to 2.3.5-? (Redhat 5.2 rpm) doesn't fix it.
Using different ppp scripts, as supplied in /usr/doc/ppp-2x still
fails. No matter what, after a few seconds of connection, or even
sometimes before then, pppd gets a SIGHUP from somewhere and dies.
I've even tried calling pppd with nohup, without success
I've tried booting from the original redhat 6.1 kernel and modules -
no success, nor with one built myself.
Commenting out ppp-watch didnt do anything for me.
I dont have a windows partition, and rely 100% on ppp for internet
access from home. And each aborted connection is costing me 20c.
I'm now to the point where I think I'll have to bring home the pppd
tarball on floppy, to comment out whatever section of code handles
Is there any way / tool to trace where this damn SIGHUP is coming
Any help would be much appreciated,
------- Additional Comments From 11/07/99 23:09 -------
After searching on usenet, a post mentioned 'insmod'ing the ppp module
before connecting. I dont claim the bugs fixed, but its enabled me to
reconnect with ppp-2.3.10-3
I'm going to write a huge omnibus reply...
Our default scripts enable "defaultroute" by default. Unfortunately,
pppd recently changed from replacing an existing default route to
complaining about it with a rather cryptic error message about
having to authenticate the remote client. (It's not cryptic if
you know how pppd works, but it's cryptic in this context...)
I'd like to know if the dial-hangup-redial-success is not fixed
for anyone. It's not loading a kernel module too late; it is
opening a new controlling tty and then closing it, which generates
a HUP. (It doesn't intend for it to be a new controlling tty, and
in many contexts, it isn't, but our scripts call pppd without a
controlling tty, so the new PTY that gets opened becomes a controlling
I'm not sure who is finding that 230400 isn't working; I fixed a bug
in wvdial where it thought it was talking 230400 but was really
talking 115200 so that might be what you are seeing.
Olorin, I'm sorry, but I can't quite parse "totally non-functional".
It works here, it works for everyone else who has reported on it
so far, so I need more details on what it is doing in order to have
a ghost of a chance of fixing it. You don't want to comment out
SIGHUP handlers because SIGHUP terminates a process by default.
"modprobe ppp" makes the problem only happen the first time you try
to dial after putting the modules in place. That fact may be a
kernel bug, but it is convenient in this context...
Everything is working great now after upgrading to
ppp-2.3.10-3.i386.rpm. Thanks for following through and finding the
Thanks for testing. The -3 release that I sent out as an official
errata release is the same package that you downloaded (the difference
in size is that the official release was GPG-signed), so you don't
need to re-get the official -3 release for any reason.
Olorin, if you can get more information, please open a different
bug report to discuss it. It's clearly not the same bug if
"ppp is now totally non-functional" so let's solve it seperately
without bothering the other folks on the CC list for this bug