Well, I finally got diald and dialmon working, thanks to help mostly found
here.
To recap, I am using RH 6.0 (2.2.5-15 kernel), diald 0.99-1, pppd 2.3.7 and
getting an IP address dynamically upon connecting to my ISP. I connect via
an external ISDN modem, which other than being fast and needing a long init
string, looks like any other external modem. That dialup connection also
uses CHAP authentication for logon. I am also using the Linux box as a
server for Internet access, DHCP, Samba, and local DNS.
I want to state the key points of my installation; at least partly, so I can
look at my saved messages or the list archives in case I forget.

1) The ifcfg-ppp0 file which the network control panel put in
/etc/sysconfig/network-scripts needed to have most things taken out of it. I
had been set up for demand dialing via pppd before I started this odyssey,
and the control panel set up this config file with options for demand
dialing, default route setting, the phone number and modem init string, etc.
I took those things out and am left with:

DEVICE="ppp0"
ONBOOT=no
PERSIST=no
DEFABORT=yes
DEFROUTE=no
DEBUG=no
ESCAPECHARS=no
PPPOPTIONS='novj -detach noipdefault'
PAPNAME=xxxx
RETRYTIMEOUT=5
BOOTPROTO=none

I only need the 'novj' because my ISP can't cope with what Win95 calls "IP
header compression".
There is also a file /etc/ppp/options where some of these things can go,
(albeit in a slightly different format - way to go, pppd designers!!). You
can put things which are truly global for all connections there, I suppose.
However, if you put tings like "defaultroute" or "ONBOOT=yes" if ifcfg-ppp0,
the pppd uses them and seems to confuse diald.

2) diald takes a command line parameter on where to get its config file
from. However, it also seems to always look for a diald.conf in the /etc
directory, possibly in addition to the command line parameter. Anyway, since
with the (almost working) 0.16 version I had the config files in the
/etc/diald directory, I thought I could leave them there by keeping the
command line parameter which started diald the same. Wrong. The diald 0.9x
installation puts a diald.conf in the etc directory and seemed to ignore
what I put into the other config file. I ended up just putting my diald.conf
into /etc. I also used the default location for the .def and .filter files
(/usr/lib/diald). Here is the resulting config file:
#
# diald.conf for mybox
#
# debug 9
#
linkname MYISP
linkdesc Connect to MYISP
# use real-time scheduler type
scheduler fifo
# set scheduler static priority
# priority 10
device /dev/ttyS0
speed 115200
modem
crtscts
lock
mode ppp
dynamic
local 192.168.1.100
remote 192.168.1.200
pppd-options novj name xxxx
defaultroute
connect "chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"
redial-timeout 5
accounting-log /var/log/diald.log
fifo /etc/diald/diald.ctl
include /usr/lib/diald/standard.filter

I am not *positive* that the "name" parameter for pppd is needed. Note that
this setup makes use of the chap script created by the network control
panel, no mods needed. I am currently playing with the "priority" value; I
did not understand the oblique reference in the man pages as to how to find
out what values are reasonable for it.
I used the standard.filter file which came with diald, but I shortened most
of the longer timeouts, plus I added a few rules to catch stuff that was
keeping the link up. I found out *what* stuff by using dialmon and tcpdump
for a couple of really tricky packets.

3) I got diald going by putting this commands towards the end of my
/etc/rc.d/rc.local file:

/usr/sbin/diald

4) At this point I had a problem, since diald would start up the connection
but not end it (which is kind of the whole point, here). The solution turned
out to be in my ipforwarding/masquerading setup. Before, for what I thought
were security reasons, I had as one of my rules:

ipchains -A forward -i ppp0 -j MASQ

Since I specified the ppp0 interface, it seems that diald (which is
monitoring the tap0 interface - I think?) couldn't perform its duties
successfully. Anyway, on advice found here I changed that line to:

ipchains -A forward -s 192.168.1.0/24 -j MASQ

which seems less secure but also seems to work. I am still playing with the
rest of my fire-walling rules but I think that overall the internal network
is secure from casual intruders.

5) Diald also needs access to a device called "ethertap" - however, it
refers to it via aliases such as "tap0" or "tap1". It doesn't give you a
hint that what it really needed was an ethertap. Anyway, to get rid of the
errors (and get diald to work) I had to add this line to /etc/conf.modules:

alias tap0 ethertap

By the way, I also have these lines:

alias ppp-compress-21 slhc
alias ppp-compress-24 bsd_comp
alias ppp-compress-26 bsd_comp
alias ppp-compress-1 bsd_comp

which get pppd to be able to do various types of compression without
complaining.

Of course it wasn't enough that this worked - I had to go and try to add
dialmon to it. Dialmon is a program which consists of a server daemon which
runs on the linux box and a client GUI which runs on Windows. The GUI tells
you when the link is up or down, why it's up, how long before it's likely to
go down, and allows you to force it up or down. It's a really neat tool, but
unfortunately the demands it put on my lowly Cyrix 133 server machine caused
diald and pppd to be erratic. As a result, I came up with the following
rules:

  Don't leave the dialmon GUI running on the windows box. It gives the
server side problems getting diald and pppd set up during bootup (in case
the server needs to reboot - not so often in  the realworld enviromnment
where I have one of these set up, but fairly often at home where I do
development and try out configurations.)
  Let dialmon start the diald process at bootup. That means my command in
rc.local is now:

/usr/sbin/dialmon -b128000 -pppp0 -rMYISP

This depends on the following content of /etc/dialmon.conf:

[host]
        port    7100
        force   90
        fifo    /etc/diald/diald.ctl
        allow   up
        ddconf MYISP "/usr/sbin/diald -daemon -f /etc/diald.conf"

# Further sections are named for the client machines. These can contain
# just the allow up, allow down, allow keep and allow set directives.
#
[win95box]
        allow up
        allow down
        allow set
        allow ctrl
...

Finally, I set up a caching-only name-server (DNS) using instructions I
found at Josh's Linux Guide. I won't get into all of that here, except to
say three things:
1) You do need this to keep the server from dialing out constantly.
2) You really only need the localhost zone file, not the other zone files he
mentions.
3) If you use expressions like 4H or 2D for the timeouts in the zone files
and then use linuxconf to look at your DNS settings, it will zap the alpha
characters. This will leave you with a system which is trying to update your
DNS cache every second or so; this can keep the link up a lot. The examples
I have seen several places do use these expressions. The are certainly a lot
clearer than always expressing the time in seconds, but linuxconf can't
cope, so beware.

I think that's the majority of the requirements.
All of this because there is UDP and ICMP JUNK coming down from the ISP.
Yes, I have tried several ISP's, and they all seem to generate this stuff
which prevents the modem from hanging up. I can see it coming in even when I
connect the modem directly to a Win95 box; Win95 DUN apparently knows what
to ignore and terminates the link at the selected time.

My thanks to those who helped with good tips.

I would like to say that the quality of info you see on the Linux groups
tends to be poorer than what you get on the (mostly moderated) Windows
groups. In particular, that "diald-mini-howto" which is still referenced
quite often is cryptic to begin with and out of date to finish. Also, some
characters will blithely post a link to an FTP site which has quite rudely
terminated with no info at all, or to sites which do *NOT* have the software
under discussion. This last fact is equally true in the Windows world,
though.

Finally, I really appreciate that this is free software and offer my thanks
to Eric and Mark for producing and maintaining it.



-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]

Reply via email to