Re: kerneld/request-route

David Flood (dcflood@u.washington.edu)
Wed, 3 Jul 1996 02:51:51 -0700 (PDT)

The problem that I had with it (and that the dreaded kerneld fixed - for now),
was that the program tries to execute pppd itself rather than executing a
script. So it was impossible to see what exactly diald was telling pppd.
A debug option of writing the pppd command line to a file so that it can
be checked would be nice. 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.

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.

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.

On Tue, 2 Jul 1996, Eric Schenk wrote:

> This trend of reinventing the wheel makes me wonder just what is
> wrong with the wheel we have. Obviously as the writer of the wheel
> I'm a bit bothered by it, since I think the wheel is pretty good.
> That said, I'm always willing to improve diald. So, let me ask,
> exactly what is it about diald that bothers some people so much?
>
> Is it the fact that it uses a SLIP link? The documentation? Something else?

=============================================================================
dcflood@u.washington.edu