Start by updating ppp to ppp-2.3.10-3 and see if that fixes the problem.

Actually I have, I pasted an old "rpm -q" by mistake.

OK, try the latest initscripts and see if that helps...  Yes, I'm
grasping at straws here...

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 ?

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.

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.

I don't have such a file, and /etc/ppp/options contains:
lock
noauth
defaultroute
debug

Where else could  it be ?

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

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.

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

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!