I upgraded my Redhat 6.0 system to 6.1 and now my PPP
connections won't dial from netcfg. I can go to minicom and
the /dev/modem device is working properly. PPP does not
dial from netcfg.
Does it work if you do
(or whatever the name of your connection is) from a
I have encountered the same problem. /var/log/messages gets filled
with complaints from pppd that no secret(passwd) is available. pppd
gets respawned until I kill a pppwatch (or something like that)
I also checked /etc/pam.d/ppp and noticed that this is the only file
without /lib/security/ preceeding pam_pwdb.so, etc., but adding the
full path did not improve things.
------- Additional Comments From 10/18/99 08:34 -------
I also have this problem. Here are some relevent lines from
brutha connect: Dialing 9974774
brutha connect: chat: Oct 17 22:58:21 CONNECT 50666/ARQ/V90/LA
brutha connect: Loggin in
brutha connect: Protocol started
brutha diald: Running pppd (pid = 842)
brutha modprobe: can't locate module char-major-108
brutha pppd: The remote system is required to authenticate
brutha pppd: couldn't find any suitable secret (password)
brutha kernel: PPP: version 2.3.7 (demand dialling)
brutha kernel: PPP line discipline registered.
brutha kernel: registered device ppp0
I have largely fixed this problem by upgrading linuxconf, turning off
IPv4 forwarding and setting no default route in netcfg, turning off IP
masq, and adding "noauth" as a ppp option. I think the crucial change
was having no default route (through eth0, anyway) and the noauth
option (see linuxconf change history concerning ppp). I have also
turned IP masq. back on (ipv4 forward=yes + several ipfwadm commands)
with no problems, so far.
BTW, this is with initiating the ppp connection using my own ppp-on
script using "ifup" or something like that (based on the FAQ in an
earlier RH manual on how to start ppp from the command line)... I
haven't tried activating the connection from within netcfg.
------- Additional Comments From 11/03/99 21:22 -------
I did a new install, from scratch, and I did not have the MODPROBE
error message. I then did a rebuild of the kernal and an install
assuming that the defconfig was loaded during 'make xconfig'.
Had the same problem. Netcfg didn't start dialing and ifup ppp0 hangs.
Dialing with minicom and kppp works fine though
Turning off the default route was what fixed it in this case.
Basically, if you already have a default route, pppd has been changed
to assume that it is running as a PPP server and to assume that it
must authenticate the connection. You can use the noauth to change
In the next version of our initscripts, we'll remove any existing
default route before asking pppd to add a default route. (Of
course, we will not remove the default route if you don't ask
pppd to set the default route.) That will remove the problem
firstname.lastname@example.org reports in private email:
>Had the same problem and error messages after upgrading
>from 6.0 to 6.1 as described in the message of email@example.com
>on the bug report page.
>ifup ppp0 wouldn't work as well as netcfg.
>After upgrading the ppp package to ppp-2.3.10-1 everything is working
>again, though the status sign in usernet isn't turning green, but
>network connection is up.
Does your modem light stay on mostly continuously? Some ISPs have
broken CCP negotiation, so ifup-post might not be called.
The answer of add "noauth" to my pppd options made it work for me using netcfg.
It took me a little longer to figure out how to pass "noauth" to pppd through
diald, but now my system is back to working as usual. Thanks for providing this
Netcfg had worked flawlessly for the last several versions. At 6.1 the lab,
quality control, or whoever is supposed to catch something that simple, didn't.
How about getting on the stick fellows. The competition is out there.
The usernet light problem should be fixed in the version of initscripts from
Raw Hide (ftp://ftp.redhat.com/pub/rawhide/i386/RedHat/RPMS/), which also
includes fixes for the "noauth" problem and all of the known problems with
The initscripts/ppp/noauth problem is fixed in the 6.2 beta (Piglet). We found
a couple of cases where the ppp-watch process started by ifup-ppp would not
quit and the ifup script would therefore never exit, but those should be fixed
in Raw Hide.
It appears that firstname.lastname@example.org has solved his problem. If things are now
working correctly for email@example.com and firstname.lastname@example.org, I'm
ready to close out this bug report.