RE: howto disable auto route setup?

David Taylor (davidt@xfiles.nildram.co.uk)
Tue, 2 Feb 1999 17:55:25 +0000 (GMT)


One reason *I* use diald is it is much more flexible - you can configure
different rulesets for different times, very useful when you have charged
per minute phone calls with different rates. I looked at the new pppd
features for, say, 30 seconds before deciding diald is much better.

David Taylor
E-Mail: dtaylor@nildram.co.uk.spam
ICQ: 268004
[Remove .spam from e-mail to reply]

On Tue, 2 Feb 1999, Fred Reimer wrote:

> I, personally, don't understand the need for diald with the dial-on-demand
> option incorporated directly in pppd since a while ago and the new ipchains
> filters. Why can't you just delete the route after the ifconfig if that is
> a requirement for you? If you must use diald can't you use ipchains to
> redirect the traffic to a ethertap interface that diald listens to?
> Something seems broken here with diald - specifically it's failure to cope
> with the implementation of some of it's key features into the "base" code
> (being the pppd daemon and the kernel).
>
> Note that I don't use diald and don't know the details on how it works.
> But, if it is simply a dial-on-demand daemon with filtering capabilities
> that I think it is, why would anyone continue to use it when that
> functionality has been incorporated into the base code? It just seems to me
> that diald is not using the new features available in the newer kernel to
> provide the functionality it tries to. It appears that the fundamental
> structure of the diald process needs to be re-examined. For instance:
>
> If diald needs to listen for specific types of traffic and, based on that
> traffic, launch a pppd daemon and take it down when necessary
>
> Then, it appears that the "best" way to do this may be to create an Ethertap
> interface and set the default route to that interface. Have diald listen on
> this interface and if it detects a packet that should cause a connection,
> fire up pppd, and resend the packet through the ethertap interface to the
> original destination. It can continue to forward and monitor the traffic and
> take down the pppd when a timeout occurs. Does this not sound like a better
> method?
>
> Fred
>
>
> > -----Original Message-----
> > From: owner-linux-kernel@vger.rutgers.edu
> > [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Mike Jagdis
> > Sent: Tuesday, February 02, 1999 4:40 AM
> > To: Sam Mortimer
> > Cc: linux-kernel@vger.rutgers.edu
> > Subject: Re: howto disable auto route setup?
>
> > I am sorely tempted to say "bollocks" to that. It may be true in
> > many cases but I doubt it is provably true in all cases and thus
> > is the Wrong Thing to impose.
> >
> > Consider an ippp link being managed by diald (which, not entirely
> > coincidentally, I have quite a few around...). The ippp interface
> > must be configured and up in order for it to accept incoming calls.
> > But the _routes_ must point through diald's proxy. When diald
> > decides the link needs to be up it initiates the call and points
> > the routes through the real interface. The proxy stays up.
> >
> > It isn't impossible to make diald work in an environment where
> > routes magically appear whenever an interface changes in some way.
> > However that isn't _always_ the right thing to do and it isn't
> > necessary to do it in kernel space when everyone is already
> > familiar with the need to set routes from user space after changing
> > an interface.
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/