>A debug option of writing the pppd command line to a file so that it can
>be checked would be nice.
Diald passes almost no options to pppd. It deals with almost everything itself.
It starts pppd with:
pppd -detach [modem] [crtscts] [mtu X] [mru Y] [netmask Z] <user-ppp-ops>
where the options in []'s are only passed if the same option is
specified to diald. Note that the options for diald are a fairly
large subset of the options for pppd. Many of them are dealt with
directly by diald, .e.g. the "connect" command.
Those pppd options that are not also diald options can be specified
on the diald command line after then "--" marker. Any such options
are simply passed on to pppd.
In any case, if you have a working pppd script of the form:
pppd <list of options>
it can probably be turned into a working diald script by changing it to:
diald <list of options>
>Or just have diald be able to execute a script.
>That way pppd's options could be debugged first and after a working script
>is developed, then getting diald to work would come next instead of trying
>to get it all working at once. Break it down into managable steps.
There good reasons diald does not just run a user script. I originally
tried this approach and ran into several serious problems. The main
difficulty is as follows.
Diald needs to know which ppp device (or slip device, diald supports slip
as well) came up so it can monitor its status. This includes watching
the traffic that passes over the link, so diald can decide if the
link is "idle" (and this is NOT just a timeout decision. You can
specify seperate timeouts for different types of traffic and even
the contents of the packet headers.) It also includes watching for
the link to just spontaneously die so it can be brought back up
immediately.
If you just run a user script to start up the link it is difficult
to determine which ppp device came up. Keep in mind that there
may be more than one ppp device up at the same time, indeed there
may even be more than one copy of diald up at the same time!
Now, I could have placed the burden on the user to somehow inform
diald of the device that came up, which was what I originally tried,
but this just turned out to be confusing.
Also, even if you find out the ppp device that is being used,
it is messy to watch for the death of pppd. You can't recover
the pid of the pppd process from the device, so you end up
checking to see if the device is still up every so often.
Even worse, it turns out that pppd can bring the device down
and then back up without ever failing (and before someone
says this must be a bug, it is allowed by the RFC's), so watching
the status of the device is not a reliable indicator of the fact
that pppd has died!
In the end I decided that the only reliable way to deal with things
was for diald to know the pid of the pppd process that got started.
The best way for diald to know this is for diald to start pppd itself,
and to start it with the "-detach" option. This way diald just
has to wait for a SIGCHLD signal to know that pppd has died.
>Also the elimination of having to specify ip addresses. In its current
>incarnation, the request-route script is called whenever ANY unknown
>destination or ip address is being requested. This is what (to me) is meant
>by On-Demand-Dialing. If it ain't on my network localy, it is probably
>"out there" and I want to connect to "out there" to get to it.
The reason you need an IP address is so that the packets being
sent to the demand device can have a source address. This is
orthoganal to the fact that the destination is unknown.
The route that is pointed at the demand device determines which
destination addresses cause dialing.
Also, it may be that YOU want to have demand dialing invoked for any
packet that is not on your local network, but this needed be the case.
For example, I have a demand dialing setup linking me to a customers site.
It only comes up for packets that are routed to the subnet I have
assigned to that customer. I also run an on demand link to the net
at large. These two links are completely seperate. It is even
conceivable that someone may want to do demand dialing to a small
number of subets, despite the fact that they have a direct ethernet
link to the internet at large. A flexible solution to demand dialing
MUST be able to address these issues.
>I do like the idea of a "demand device" that the default route entry could be
>pointed to. Then that device would trigger dialing. That would eliminate the
>objection to kerneld's approach of taking control away from the kernel.
This is exactly what diald already implements.
David, don't take this as flame, but did you actually read through
the diald docmentation before deciding not to try it? Is the documentation
just too damn intimidating, or have I just been increadibly unclear in it?
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto