Problem with pppd autodial is that it has no provisions for not brining up
the dial-on-demand for certian types of packets (i.e. the link doesn't
come up for them, but if they come while the link is up then they still go
through).. This feature keeps name RR's from bringing up the link
constantly..
Currently I've got ppp executing a script on up and down to ipchain out
that packet type.. Not a very good solution.
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
-
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/