On Wed, 18 Nov 1998, brian beuning wrote:
> 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.
I believe you can do this now by running 2 dialds. The situation that
others have brought up is when there are hundreds of remote sites, in
which case running hundreds of dialds isn't really practical.
> 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.
It should have dropped A by then regardless of whether B wants to come up.
> 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.
I agree with this. If diald were modified to handle multiple remote
sites, we could get away with using one dialing script if diald passed the
relevant IP address to the script in an environment variable.
Ed
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
