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
connection.

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
Hat?

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
/sbin/ppp-watch or

ifup-ppp script.

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
block:
if ......
   exec /sbin/ppp-watch "$@"
fi
shift

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
information/sugestions?

From my experimenting it seems that the problem is either a buggy or
broken /sbin/ppp-watch

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
information/suggestions?

Thanks in Advance

Please try
ftp://people.redhat.com/johnsonm/ppp-2.3.10-3.i386.rpm
and see if it fixes this problem for you.

After upgrading to the rpm ppp-2.3.10-3 ppp is now totally non-
functional
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
SIGHUPS.
Is there any way / tool to trace where this damn SIGHUP is coming
from?

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
tty.

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
problem

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
report.  Thanks.