Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7234 - rp3-created connection doesn't work, ppp script fails
Summary: rp3-created connection doesn't work, ppp script fails
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp3
Version: 6.1
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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
115200
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
115200
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
DEVICE=ppp0
NAME=Free
WVDIALSECT=Free
MODEMPORT=/dev/ttyS0
LINESPEED=115200
PAPNAME=rguerin
USERCTL=true
ONBOOT=no
DNS1=212.27.35.5
DNS2=212.27.35.6


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

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
end.

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

Where else could  it be ?

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

rpm -q wvdial
rpm -V wvdial

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

Try
  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
+ 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)
  shift
  # let ppp-watch do the right thing
  exec /sbin/ppp-watch "$ifcfg" "$@"
fi
+ [ 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
syslog)

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
wvdial-1.40-5
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"
 else
   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
options...

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
  make
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/,
etc.

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.