Messages in this thread |  | | Date | Wed, 3 Jul 1996 02:51:51 -0700 (PDT) | From | David Flood <> | Subject | Re: kerneld/request-route |
| |
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
|  |