Messages in this thread | | | Date | Tue, 2 Feb 1999 17:55:25 +0000 (GMT) | From | David Taylor <> | Subject | RE: howto disable auto route setup? |
| |
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/
| |