Specifying a "range of outgoing addresses" would not cover a lot of
cases (and mine in particular). I think many people would like to be
able to set up diald for calling a couple of sites. Each site has general
internet connectivity but also has access to a few IP addresses that are only
accessible when using the connection to that site. Consider an ISP SMTP
server which only allows connection from IP addresses within the ISP.
My SMTP server at work has the came rule, but it only allows work IP
addresses. The same is true for many NNTP servers.
So I would want to tell diald these rules:
1. Connection A (to my ISP) is a default route EXCEPT to this range of (work) IP
addresses.
2. Connection B (to my work) is a default route EXCEPT to this range of (ISP) IP
addresses.
Then if diald has connection A up and a request for a work IP addresses is seen,
diald
would need to bring up connection B also. If diald was very smart, it might be
able to
drop connection A if B is up, and it has not seen any ISP only addresses in a
long time.
Actually I do not think it would be a good design to embed too much "dialing
policy" logic
in diald itself. Users are going to want lots of different policies. It would
probably be better
if diald ran some user provided script and the script made policy decisions. To
implement
the "bandwidth on demand" type of feature diald would also need to invoke a
policy
script to decide when to disconnect a link.
Brian Beuning
Eric Schenk wrote:
> Mike Jagdis <[EMAIL PROTECTED]> writes:
>
> > On Thu, 12 Nov 1998, David Douthitt wrote:
> > > Would it be possible to convert diald to spawn children attached
> > > to particular ttys when a request comes for a dialout (kind of the
> > > way inetd does it)? This would necessitate combining multiple
> > > dialout configurations into the configuration files. It would also
> > > prevent 100s and 100s of dialds hanging out doing nothing, since a
> > > diald "child" only appears when a dialout occurs. Any thoughts?
> >
> > At the moment diald has an awful lot of global stuff that needs
> > to stacked, wrapped, and packed. Once that is done it shouldn't
> > be overly difficult to have a single proxy, feed incoming packets
> > through some routing rules and off to the relevant link. In theory.
> > The routing is probably the trickiest bit but if the kernel can
> > do it so can we - or at least we can steal it :-).
>
> Actually, the routing isn't that tricky. I'd always planned to write
> a diald version 2 that did just this. The idea was to specify a
> connection in terms of a range of outgoing addresses and have just
> one config file that defined all the connections diald knew about.
> Since you only need to do "routing" type stuff on packets you see
> on the slip interface, the speed of this routing isn't super critical.
> I'd go for the binary trie routing algorithm here (as opposed to the
> multi level hash table scheme used in the kernel). It's pretty easy
> to implement, and I think I might even have some code lying around
> I can throw at you from my preliminary work on this a couple
> of years back.
> Once a new connection is established and we have a ppp up and running,
> the routing is back in the kernel. There are probably a few tricky
> issues in making sure there isn't a "route free" window when
> connections get torn down, but it should be possible to manage this.
>
> (Mike, we should talk a bit about the stuff I have lying around here,
> and what we should be doing with the loonie web site. I'll drop you
> a line in the next day or so with a description of what I have around here.)
>
> --
> Eric Schenk www: http://www.loonie.net/~eschenk
> email: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
