Bug 7234 - rp3-created connection doesn't work, ppp script fails
Summary: rp3-created connection doesn't work, ppp script fails
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp3
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-22 20:11 UTC by renaudg
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-12-07 15:58:32 UTC

Attachments (Terms of Use)

Description renaudg 1999-11-22 20:11:20 UTC
I created a ppp connection using rp3-config.
It won't connect with rp3, nor with "ifup ppp0"

It seems to be in loop where it respawns pppd and it fails and ...
Here's my syslog:
Nov 22 21:12:10 saturne ifup-ppp: pppd started for ppp0 on /dev/ttyS0 at
Nov 22 21:12:10 saturne modprobe: can't locate module char-major-108
Nov 22 21:12:10 saturne pppd[1153]: pppd 2.3.10 started by root, uid 0
Nov 22 21:12:11 saturne pppd[1153]: Connect script failed
Nov 22 21:12:12 saturne pppd[1153]: Exit.
Nov 22 21:12:12 saturne ifup-ppp: pppd started for ppp0 on /dev/ttyS0 at
Nov 22 21:12:12 saturne modprobe: can't locate module char-major-108
Nov 22 21:12:12 saturne pppd[1163]: pppd 2.3.10 started by root, uid 0
Nov 22 21:12:13 saturne pppd[1163]: Terminating on signal 15.
Nov 22 21:12:13 saturne pppd[1163]: Connect script failed
Nov 22 21:12:14 saturne pppd[1163]: Exit.
[...and so on...]

I haven't hand-edited anything in /etc/rc.d/network-scripts/, the modem is
okay, and it works with kppp.

saturne:[root]:/etc/sysconfig/network-scripts->cat ifcfg-ppp0

Latest errata installed:
saturne:[root]:~->rpm -q initscripts ppp rp3

I realise this isn't very detailed, but I don't know where to look next...

Comment 1 Michael K. Johnson 1999-11-23 16:43:59 UTC
Start by updating ppp to ppp-2.3.10-3 and see if that fixes the problem.

Comment 2 renaudg 1999-11-23 20:59:59 UTC
Actually I have, I pasted an old "rpm -q" by mistake.

Comment 3 Michael K. Johnson 1999-12-01 21:03:59 UTC
OK, try the latest initscripts and see if that helps...  Yes, I'm
grasping at straws here...

Comment 4 renaudg 1999-12-02 19:45:59 UTC
Got initscripts-4.70-1, nothing's changed.
Is there a way I can make pppd more verbose to find out where the script fails ?
BTW, which script do you think it's running ?

Comment 5 Michael K. Johnson 1999-12-02 21:01:59 UTC
echo 'DEBUG=yes' >> /etc/sysconfig/network-scripts/ifcfg-ppp0
(or ppp1 or ppp2 or whatever; make sure you use >> and not >)

I don't understand your last question about what script I think
it is running.

Comment 6 Kristopher D. Giesing 1999-12-04 05:57:59 UTC
I had this problem on my own system.  The problem was that I had a /root/.ppprc
file.  pppd was trying to use the "connect" script specified in that file, and
since WvDial had already initialized the modem and dialed, the connect script
from /root/.ppprc was failing, causing pppd to fail.

I'm guessing this is the problem here, since it can't be reproduced at the RH

Comment 7 renaudg 1999-12-05 12:43:59 UTC
I don't have such a file, and /etc/ppp/options contains:

Where else could  it be ?

Comment 8 Michael K. Johnson 1999-12-06 20:27:59 UTC
I think that kgiesing is on the right track here.  There are
no messages in /var/log/messages from WvDial (at least, none are shown

rpm -q wvdial
rpm -V wvdial

It really doesn't look like wvdial is getting called at all.

  strace -fo /tmp/ppp.st /sbin/ifup ppp0
and then look through /tmp/ppp.st to see what script it is trying
to call.  It should be near the end.

Comment 9 renaudg 1999-12-07 10:38:59 UTC
Ok, strace produced *much* output, so I chose to add "set -vx" at the beginning
of "ifup-ppp" instead :

+ PATH=/sbin:/usr/sbin:/bin:/usr/bin

# ifup-post for PPP is handled through /etc/ppp/ip-up

if [ "$1" != daemon ] ; then
  # just in case a full path to the configuration file is passed in
  ifcfg=$(basename $1)
  # let ppp-watch do the right thing
  exec /sbin/ppp-watch "$ifcfg" "$@"
+ [ ifcfg-ppp0 != daemon ]
basename $1
++ basename ifcfg-ppp0
+ ifcfg=ifcfg-ppp0
+ shift
+ exec /sbin/ppp-watch ifcfg-ppp0

(it hangs there, it's in some kind of loop because the TR/SD/RD lights on the
modem flash every 1/2 second and there's HD activity, corresponding to the

and indeed, in strace /sbin/ppp-watch ifcfg-ppp0 :

2045  open("/etc/sysconfig/network-scripts/ifcfg-ppp0", O_RDWR) = 0
2045  fstat(0, {st_mode=S_IFREG|0644, st_size=164, ...}) = 0
2045  read(0, "DEVICE=ppp0\nNAME=Free\nWVDIALSECT"..., 164) = 164
2045  fork()                            = 2047
2045  rt_sigsuspend(~[HUP INT TERM CHLD IO] <unfinished ...>
2047  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
2047  setsid()                          = 2047
2047  setpgid(0, 0)                     = -1 EPERM (Operation not permitted)
2047  execve("/etc/sysconfig/network-scripts/ifup-ppp",
["/etc/sysconfig/network-scripts/i"..., "daemon", "ppp0"], [/* 41 vars */]) = 0

it starts ifup-ppp again.

As for wvdial:
saturne:[root]:~->rpm -q wvdial
saturne:[root]:~->rpm -V wvdial
SM5...GT c /etc/ppp/peers/wvdial
S.5....T   /usr/bin/wvdial
S.5....T   /usr/bin/wvdialconf

This is a patched version which solves the other problem I had with wvdial not
detecting a connection.

Comment 10 renaudg 1999-12-07 11:55:59 UTC
Sorry for the nonsense above, I hadn't looked at the ppp-watch source yet and I
didn't know it was supposed to call ifup-ppp again with the daemon arg :)

Anyway, I think I've found the problem :

wvdial didn't like the way it was called from within ifup-ppp, --remotename
doesn't seem to exist (I get the "usage" message from wvdial when I call it
manually with "wvdial --remotename ppp0 --chat Free")

So all I had to do was:

--- ifup-ppp.old	Tue Dec  7 12:54:05 1999
+++ ifup-ppp	Tue Dec  7 12:54:25 1999
@@ -99,7 +99,7 @@
     linkname $DEVICE \
     noauth \
     ${PPPOPTIONS} \
-    connect "/usr/bin/wvdial --remotename $DEVICE --chat $WVDIALSECT"
+    connect "/usr/bin/wvdial --chat $WVDIALSECT"
   exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \
     remotename $DEVICE ipparam $DEVICE \

It seems very strange to me that I was the only one having this problem. I don't
think that the patch I applied to wvdial had anything to do with command line

Comment 11 Michael K. Johnson 1999-12-07 15:58:59 UTC
Did you download wvdial from worldvisions, or did you use our patched
source?  The --remotename argument is something we added for integration
with initscripts.  The wvdial authors want to eventually provide the
ability to give that information in a more general way, and so are not
accepting our patch, though they don't mind us putting it in our version.

I'd suggest that the best way to build yourself a new wvdial is to do
  rpm -i /path/to/SRPMS/wvdial-1.40-5.src.rpm
  cd /usr/src/redhat/SPECS
  rpm -bp wvdial.spec
  cd ../BUILD/wvdial*
  patch ... < path/to/your/patch
unless you want to actually build yourself a new RPM, in which case you
have to edit wvdial.spec and put your patch in /usr/src/redhat/SOURCES/,

By doing it my way, you get all our patches applied first.  You can apply
this to any software of ours you want to rebuild with a change.

Hope that helps!

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