Bug 6291

This problem also affects usernet; if usernet is used to bring up a
PPP interface using demand-dialling, the "Waiting for Connection"
window never goes away even after the interface is, for purposes of
demand dial, up.  Presumably the same problem.

I have the same problem, and found the following workaround:

(1) modify ifup to pass the "daemon" option to ifup-ppp taking control
away from ppp-watch. I was tired last night and lazy so hardcoded it
whilst testing, sooner or later I'll get around to fixing ifup so it
passes that option if "demand" is one of the pppd options but
obviously I'd rather see an "official" fix :)

(2) you also need to fix ifup-ppp so that it forks pppd instead of
hanging onto it - otherwise ifup-ppp will never return until you kill
pppd. I just modified the 2 lines that start "exec pppd -detach ...."
to get rid of the "exec" and "-detach" Whatever else happens this mod
is a good idea since if the ifup-ppp script gets here at all we are
supposed to be starting a daemon process and so why hold on to it and
stop it forking?????

As things stand at the moment those mods break ifdown-ppp, since
ifdown-ppp depends on ppp-watch establishing the pid file you have to
kill pppd to force the interface down. "ifdown ppp0" wont do it.

Alternatively, you could modify ppp-watch so that it can also act as a
wrapper around demand-dialling configs but I havent even started to
address that one since there isnt any documentation on ppp-watch and I
havent gotten around to searching throught the SRPMS for the source...

POSSIBLE FIX: A much neater solution than the crude workaround from my last
comment. modified ifup-ppp and ifdown-ppp scripts to treat demand dialing as a
special case. ifup-ppp checks both for the "daemon" option or for a demand-dial
config before acting. if neither passes control to ppp-watch as normal,
otherwise proceeds to start pppd. If its a demand-dial config dont try and be
synchronous just start it, otherwise behave as ppp-watch expects. ifdown-ppp
also checks for a demand-dial config if it cant find the ppp-watch pid file and
if it is demand-dialled looks for the pppd pid file instead. when killing the
process if the first SIGTERM doesnt bring it down a demand-dialling pppd is sent
a SIGKILL directly whilst a ppp-watch controlled pppd is dealt with as at
present. This works fine on my system (vanilla RH6.1 install) but YMMV. mail me
if you want my modified scripts.

Just to give you a few more ideas how to do an official fix I'll tell you about
my workaround.  Things hang because ppp-watch isn't told by any do_netreport
call.  That is since ifup-post is called from ip-up, which isn't executed until
the connection actually is up.

So I added a couple of "(sleep X; do_netreport)&" lines before pppd is exec'ed.
I used a few different values for X.  That causes in effect ppp-watch to poll
att these times, and sees that the interface is up at one of them.

Similarily, I added a couple of do_netreport calls between the checks on
/proc/PID in ifdown-ppp.

Dave's suggestions make the most sense, but to act on them we need to
extend the ifcfg format to have something like
DEMAND=yes
in them so that we can easily check to see whether demand dialing
is being done.  This may require changes in rp3 as well, though.

We chose not to explicitly support pppd demand dialing so far in part
because of reports of problems with it unrelated to our scripts, and
in part because while we were doing the development, demand dialing
with a non-static IP was not supported.  We'll have to look into it
again for our next release.

You probably dont need to change the ifcfg format, its relatively trivial to
test for "demand" in the PPP_OPTIONS string. I'll mail the mods I made directly
to johnsonm, but in brief summary the only overhead it imposes is to
require ifup-ppp to get the config info *before* deciding whether or not to call
ppp-watch and changing the ifcfg format would impose the same condition so I
suspect its a moot point. Anyway, mail is on the way (fron dbooth
since I'm at work right now...) I suspect you dont need to do much more than
that. I'd be interested to find out whether those mods would, in fact, break
rp3... I dont think so but I'm not sure.

I'm not going to look through the options, that makes for less
readable code.  We expand the list of defined tags for the ifcfg
files when we want to do something like this.  Keeps the code
more readable.

hmm, you already do in places.. not the options line but you do the "echo ...
|grep -q ..." thing for other parameters so it didnt seem much of much..

Fair enough, however you want to handle it :) pardon me whilst I just intercept
that email at the gateway...

$ grep grep ifup-ppp
$

In some scripts, we don't have the option of keeping things as clean
as we would like, but at least in ifup-ppp we don't need to make
things harder for ourselves...  :-)

Anyway, thanks!

Regardless of the technical issues:  To me it would make sense to have a
supported way to configure demand dialing, and the corresponding timout, without
having to rely on free form PPPOPTIIONS.

Yes, of course it would make sense!  There's no argument about that.
The point is that there currently isn't one.

*** Bug 9552 has been marked as a duplicate of this bug. ***

By now initscript supports a "DEMAND=yes" configurations.  So this bug can presumably be closed now.  Right?

Right.  Closing.