|Product:||[Retired] Red Hat Linux||Reporter:||roberts|
|Component:||ppp||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||6.1||CC:||atanas, chuck.d, ferrelli, iwade, ramiro, tix|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-12-14 01:21:34 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description roberts 1999-11-02 15:19:49 UTC
On all instances of RedHat 6.1 installs I am left unable to use modem devices. If I use the ppp Dialer I get messages in /var/log/messages of: can't locate module char-major-108. The second message that appears in the message log is: The remote system (ppp0) is required to authenticate itself but I couldn't find any suitable secret (password) for it to use to do so. If I try to activate the ppp0 connection from the control-panel I get: Failed to activate /etc/sysconfig/network-scripts/ifcfg-ppp0. I look in /var/log/messages and get the messages that appear in the about statement. It is important to note that I am getting this on all machines were I install RedHat Linux 6.1.
Comment 1 iwade 1999-11-06 05:49:59 UTC
same problem here .. multiple installs where i'm at too. the only reference to char-major-108 i could find was in the README.linux file for pppd /usr/doc/ .. it stated that this was a new architecture for pppd which was for kernel 2.3 .. so why is 2.2.12-20 trying to use it?
Comment 2 Michael K. Johnson 1999-11-06 19:10:59 UTC
Second question first: it is trying the new architecture in case you are running a 2.3 kernel -- this means that if you choose to upgrade your kernel, pppd will not suddenly quit working for you. Are you using CHAP authentication? I'm not sure what you mean by "the about statement" but are you getting errors about CHAP authentication failing?
Comment 3 iwade 1999-11-07 00:46:59 UTC
I've tried creating connections in three different (sorta) ways, all with the same results: 1. netcfg 2. the new rp3 3. the ppp- on/on-dialer/off scripts the first 2 use pap/chap as far as i know .. i used defaults - no connection scripts. the ppp-on scripts use chat scripts to login/authenticate. all three produced the same results, a lot of hard disk activity as it repeatedly wrote syslog message re: char-major-108 and couldn't find secret etc.. also, the diallers never even managed to get the modem to dial .. it repeatedly took the modem on/off hook .. the light went histerical :) this was a fresh install in both custom mode and gnome workstation. (irrelevant side note: the chat scripts generated by RP3/netcfg for pap/chap in /etc/sysconfig/network-scripts/ have a last line of 'CONNECT' '' this sends a CR after seeing CONNECT which causes the equipment my isp used to use -- bay networks versalar(sp?) 8000 -- to enter CLI authentication mode .. a bad thing. doesn't happen anymore since we've switched to cisco.. but i thought i'd mention it..is there a reason for the ''?) ------- Additional Comments From 11/06/99 23:47 ------- Whoa .. i just re-installed rh61 again, this time it is working .. only things i did different where choose an outrageous X theme and not tick 'let PPP do all authentication' .. i wonder which made the difference ;) i did have the problem i've seen discussed elsewhere tho' -- first connection failed, subsequent re-dial succeeded w/o any changes.
Comment 4 Michael K. Johnson 1999-11-08 15:25:59 UTC
The "remote sytem ... is required to authenticate itself" is a new "feature" in pppd where it will no longer replace the default route, so if you have, for example, an ethernet connection that has set the default route, then you can't use the ppp option "defaultroute", which we set by default in our startup scripts as it is the right thing to do for normal dialup connections. I've asked the pppd maintainer about changing this. rp3 never creates a chat script. The CONNECT '' is to wait for CONNECT and then tickle the modem. It can be changed to CONNECT '\c' if you don't want the modem tickled. Not checking "let PPP do all authentication" lets wvdial (the engine that does the dialing when rp3 sets up the connection) try to do login/password authentication. The double-dialing problem seems to be solved (please test it) by the test release of pppd that I've put at ftp://people.redhat.com/johnsonm/ppp-2.3.10-3.i386.rpm
Comment 5 Michael K. Johnson 1999-11-18 16:46:59 UTC
Two additional pieces of information: the current initscripts from the errata add the "noauth" option when calling pppd to use wvdial so that] CHAP works, which has the additional effect of making pppd come up with defaultroute specified even if there is a default route. However, it will not replace the default route, which means that the connection will not work very well... Our upcoming initscripts release adds "noauth" for connections being done in our old style with a chat script, and also deletes any existing default route if the defaultroute option is being used (that is, the DEFROUTE=yes line is in the /etc/sysconfig/network-scripts/ifcfg-ppp<n> file.
Comment 6 atanas 1999-11-26 11:12:59 UTC
I have similar problem and isolated the buggi package. 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.
Comment 7 rlarson 1999-11-29 04:10:59 UTC
Say, the blurb on the 4.68-1 initscripts indicates that the default route problem was fixed, and lists this bug ID (6646) as one of those fixed by this release. I do not agree with this optimism. On installation of the 4.68-1 package I was unable to get ppp defaultroute to work without hammering it with "route add default ppp0". Doubleplus ungood to release a package twice with the same bug especially if is marked 'fixed'.
Comment 8 Harsha Vadlamudi 1999-11-29 20:41:59 UTC
I installed 6.1 recently. It was a fresh install and I cannot get PPP to work. The messages are similar. I tried through wvdial and minicom as well. When I tried with minicom, I was actually assigned an IP number. I then did a C-A Q (quit without reset from minicom) and tried to start the pppd when it said 'remote user needs to authenticate itself, but i could not find ....' when i try through wvdial, it keeps going in a loop and the message is pppd exited with status 1. it also kept giving me the 'modprobe cannot find module char-major-108 error' error. if i use pppd with noauth also it didnt work.
Comment 9 shane 1999-12-17 22:16:59 UTC
I ran redhat 5.5 for a long time. I recently got a new system and put redhat 6.1 on it. New install. I had PPP running on the old system, but I can't get it to run on this one. I get the same "modprobe cannot find module char-major-108 error" How did you fix this?
Comment 10 tix 2000-01-30 01:40:59 UTC
I get the suitable secret error on all 6.1 boxen I have installed. Here is copy of the syslog: Jan 28 19:32:56 phoenix ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Jan 28 19:32:56 phoenix modprobe: can't locate module char-major-108 Jan 28 19:32:57 phoenix kernel: CSLIP: code copyright 1989 Regents of the Univer sity of California Jan 28 19:32:57 phoenix kernel: PPP: version 2.3.7 (demand dialling) Jan 28 19:32:57 phoenix kernel: PPP line discipline registered. Jan 28 19:32:57 phoenix kernel: registered device ppp0 Jan 28 19:32:57 phoenix pppd: The remote system (ppp0) is required to auth enticate itself but I Jan 28 19:32:57 phoenix pppd: couldn't find any suitable secret (password) for it to use to do so. Jan 28 19:33:00 phoenix ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Jan 28 19:33:00 phoenix modprobe: can't locate module char-major-108 Jan 28 19:33:00 phoenix pppd: The remote system (ppp0) is required to auth enticate itself but I Jan 28 19:33:00 phoenix pppd: couldn't find any suitable secret (password) for it to use to do so. Jan 28 19:33:01 phoenix ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Jan 28 19:33:01 phoenix modprobe: can't locate module char-major-108 Jan 28 19:33:01 phoenix pppd: The remote system (ppp0) is required to auth enticate itself but I Jan 28 19:33:01 phoenix pppd: couldn't find any suitable secret (password) for it to use to do so. Jan 28 19:33:01 phoenix ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 This repeats until I kill pppd or down the interface (ifdown ppp0). I have upgraded pppd and initscripts with no change. As you can see from the timestamps there is no time for the modem to dial, but I do get the modem light activity as mentioned above. These same systems worked without fail until upgrading to 6.1 (I back up and do a clean install to upgrade.) Thanks.
Comment 11 tix 2000-01-30 01:49:59 UTC
Forgot to add to the above: I only see this error on the server or custom install and when NOT using rp3 (not installed by default in server). Workstation installs and configured with rp3 work fine after upgrading.
Comment 12 Nalin Dahyabhai 2000-01-31 13:20:59 UTC
Anyway, jwade, roberts, tix, atanas, I suspect you all have NICs in your computers, and pppd, deducing that it will be granting access to your network to the other end of the PPP link, now requires the other end to authenticate itself before it will allow a connection. Of course, your ISP's server isn't configured to do this, so the connection fails. Either adding "noauth" to /etc/ppp/options or upgrading to the latest errata for initscripts should fix the problem. Shane, the warning message regarding char-major-108 is normal and harmless; they are caused by pppd's attempts to talk to your kernel as if it were part of the development 2.3 series, and not the stable 2.2 series. If you're having problems, please upgrade both the ppp and initscripts package to the latest errata releases and see if things still fail. If you continue having problems, please follow up with more details. Hvadlamu, try changing the line in /etc/sysconfig/network-scripts/ifup-ppp that currently reads: exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \ to: exec strace -f -o /tmp/ppp.strace /usr/sbin/pppd -detach $opts $MODEMPORT $MODEMSPEED \ and then re-run your connection attempt and send in the contents of the /tmp/ppp.strace file. If pppd is exiting with an error ID of 1, something unexpected (like running out of memory) is killing pppd, and the strace output will probably help me figure out what's going on here. Rlarson, there are probably multiple problems in this single bug ID, so an update that claims to fix it probably only fixes one of them. Usually, multiple different problems get filed as different bug reports. I can't be sure, but 4.68 probably fixed the noauth problem.
Comment 13 tix 2000-01-31 16:35:59 UTC
Thanks!! I upgrade to: initscripts-4.70-1.i386.rpm ppp-2.3.10-3.i386.rpm pam-0.68-10.i386.rpm These corrected the above "no-auth" problem.
Comment 14 Brent Fox 2002-06-05 04:47:04 UTC
Is anyone still seeing these issues with the current release (Red Hat Linux 7.3)?
Comment 15 tix 2002-06-05 06:18:28 UTC
I haven't seen this bug since upgrading to: initscripts-4.70-1.i386.rpm ppp-2.3.10-3.i386.rpm pam-0.68-10.i386.rpm as in my previous post. All versions after 6.1 have been installed on this same laptop without problems. Currently running 7.3, with all updates, and haven't seen any ppp problems.