Red Hat Bugzilla – Bug 5601
I upgraded my Redhat 6.0 system to 6.1 and now my PPP connections won't dial from netcfg.
Last modified: 2008-05-01 11:37:52 EDT
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 ifup ppp0 (or whatever the name of your connection is) from a shell prompt?
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) process.
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 /var/log/messages: 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[519]: Running pppd (pid = 842) brutha modprobe: can't locate module char-major-108 brutha pppd[842]: The remote system is required to authenticate brutha pppd[842]: 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 this. 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 for everyone.
untersta@mailer.uni-marburg.de 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 ptak@snooker.phys.edu.net >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 facility.
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 default routes.
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 ryan@csmonitor.com has solved his problem. If things are now working correctly for cameron@sound.net and ptak@snooker.phys.cmu.edu, I'm ready to close out this bug report.
Closing.