Red Hat Bugzilla – Bug 6295
PPP issues with 6.1 release
Last modified: 2008-05-01 11:37:52 EDT
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: The remote system (ppp0) is
required to authenticate itself but Ig pppd: 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
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
2. I'll look into that. I didn't intentionally change it to turn
3. Please try
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:
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
[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
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.
email@example.com: 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
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'