Hide Forgot
Upgrading from a 6.0 configuration in which PPP to my ISP was working fine for months I ran into the following: 1. Initially when I booted 6.1 for the first time after upgrade ppp went into a loop endlessly logging: Oct 23 17:00:43 pig pppd[10570]: The remote system (ppp0) is required to authenticate itself but Ig pppd[10570]: couldn't find any suitable secret (password) for it to use to do so.fup-ppp: pppd started for ppp0 on /dev/modem at 115200 Oct 23 17:00:43 pig modprobe: can't locate module char-major-108 This went on several times a second at the maximum speed the various processes would allow logging. After some investigation I discovered that there was no "noauth" in /etc/ppp/options and that putting noauth in the options seems to fix this looping behavior. The 6.0 configuration worked fine with no noauth in the options. I do not use PAP with this ISP which requires a login and password instead, It appears that the current version of pppd defaults to pap authenciation, at least when used with redhat ifup scripts, whilst the old version did not. 2. In the course of tracking this down, I discovered that pppd logs to syslog using LOG_LOCAL2 as it's subsystem ID. The previous (6.0) version of pppd used LOG_DAEMON. Looking at the source it becomes apparent that when pppd is compiled with its debug options turned on (any of them) it logs to LOG_LOCAL2 else it logs to LOG_DAEMON. This may seem a minor nit, but it screws up those who have log filtering scripts set up. 3. I have also noticed, as others have reported, that the first connect fails followed by success.
1. This is new pppd behaviour when a default route already exists. Many users dislike it and I'm talking with the author of pppd about changing it. 2. I'll look into that. I didn't intentionally change it to turn on debugging. 3. Please try ftp://people.redhat.com/johnsonm/ppp-2.3.10-3.i386.rpm and see if it fixes this problem for you.
1. Our next release of initscripts will fix this problem by explicitly removing the default route before calling pppd if we want pppd to set the default route. 2. I did not turn on debugging, and in fact, with the build instrumented with #error where LOG_LOCAL2 was used, it does not look like it is being used. Can you double-check that logging problem with the updated ppp package and make sure it is still happening for you, and that you do not have any other pppd installed on the system?
I have similar problem: I have upgraded from Red Hat 5.2 to 6.1. After that ppp connection still worked until i updated all available packages using Update Agent several times. After last update ppp stopped to work: I worked to isolate the problem to single package and it is: initscripts-4.68-1.i386.rpm I installed the prev. version - initscripts-4.63-1.i386.rpm - and after rebooting the system ppp worked properly. I installed back latest version - initscripts-4.68-1.i386.rpm - and ppp das not want to work at all. When starting ppp directly by /usr/sbin/pppd response is: [root@localhost atanas]# /usr/sbin/pppd /usr/sbin/pppd: The remote system is required to authenticate itself but I /usr/sbin/pppd: couldn't find any suitable secret (password) for it to use to do so.
There is an additional issue with both the stock PPPD package (off the retail 6.1 CD), and the update (2.3.10 Rel 3, built Sat 06 Nov 1999 on porky.devel.redhat.com): When a request for a particular IP is made either on the command line "pppd ttyS2 115200 172.16.5.20:0.0.0.0", or in an options file, it seems to be ignored. I've been forced to downgrade to an older pppd to make this feature work. I've also noticed the mysterious "dev-major-108" messages, and alternate fail/success dialout attempts.
peter@luno.org: please file a separate bug report about the ignored ips. the dev-major-108 stuff is not a bug, just ignore it. If you get the double-dial with 2.3.10-3, I want to know about it, but file a separate bug report.
The error messages that state that the remote system is required to authenticate itself can be solved by adding the "noauth" option to /etc/ppp/options. This should be fixed in the latest initscripts errata release.
Closing as 'currentrelease'