I saw the message from Edward Doolittle; there are several points (and questions) I
would like to make.
First, I am running such a setup currently, and it works well. My set up is slightly
different.
Instead of /etc/att.diald.conf, etc., etc. I use this form: /etc/diald/berbee/.... and
/etc/diald/cuna/.... All of the files have the same names, but are in different
directories. This makes it easier to program shell scripts, etc. It also shortens
the length of the names you have to remember or type.
Secondly, the files att.diald and mindspring.diald are not necessary; you could use
this snippet in your shell script:
for i in att mindspring
do
diald -f /etc/$i.diald.conf
done
and all would be well.
Also, what is the purpose of att.downroute? I don't have thus, and it works well -
but then I don't have a default route established either.
FYI, my configuration is this:
One route is to Berbee Information Networks (www.berbee.com) my ISP. One route is
to my work (CUNA). Both operate through the same modem. I also have dialup
capabilities (again on the same modem) as well as fax capabilities. This is all
because of mgetty+sendfax and diald - and all respect locks on /dev/ttyS* (modem
devices).
The only problem I have right now is my "ignore rules" for my ISP-based link don't
seem to catch everything. Also, perhaps it would be a good idea to add the reserved
private routes to the standard dialup filters? Also, a script to list the filters
with numbering (and the services with numbering) for use with debugging would be nice.
I'll probably roll my own...
Also, my diald goes up spontaneously when I don't want it to. I managed to track one
cause back to xntpd - even though ntp was ignored the first inital DNS request was
not. How do I determine exactly what IS raising diald? I can see the tcpdumps, and
all - is there any way to peg a port or connection directly back to an app? I suppose
not.
....dave
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
