Bug 5601 - I upgraded my Redhat 6.0 system to 6.1 and now my PPP connections won't dial from netcfg.
I upgraded my Redhat 6.0 system to 6.1 and now my PPP connections won't dial ...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: netcfg (Show other bugs)
6.1
All Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-05 17:08 EDT by cameron
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-03-09 17:57:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cameron 1999-10-05 17:08:34 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.
Comment 1 Michael K. Johnson 1999-10-07 15:08:59 EDT
Does it work if you do
ifup ppp0
(or whatever the name of your connection is) from a
shell prompt?
Comment 2 ptak 1999-10-14 12:50:59 EDT
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.
Comment 3 ptak 1999-10-14 13:12:59 EDT
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
Comment 4 ptak 1999-10-18 16:09:59 EDT
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'.
Comment 5 untersta 1999-11-15 18:49:59 EST
Had the same problem. Netcfg didn't start dialing and ifup ppp0 hangs.
Dialing with minicom and kppp works fine though
Comment 6 Michael K. Johnson 1999-11-18 11:42:59 EST
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.
Comment 7 Michael K. Johnson 1999-11-18 21:16:59 EST
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.
Comment 8 Ryan Finnin Day 1999-11-21 10:53:59 EST
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.
Comment 9 Paul Rowland 2000-01-08 18:35:59 EST
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.
Comment 10 Nalin Dahyabhai 2000-02-07 10:15:59 EST
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.
Comment 11 Nalin Dahyabhai 2000-03-09 17:57:59 EST
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.
Comment 12 Brent Fox 2002-06-05 00:19:53 EDT
Closing.

Note You need to log in before you can comment on or make changes to this bug.