There seem to be quite a number of small networks, either at home or at small companies, which use Windows (be they 3.1 or 95/98/NT workstation) clients, and a Linux box as a dial-up router to the InterNet at large. A common setup is to use IP masquerading, so that the the clients can hide behind a single IP address, with diald, the dial-on-demand daemon, so that the Linux box connects as and when required. This works pretty well
The real problem with this is that users on the Windows clients have no real indication of the state of the dial-up link. So, if a connection fails to materialise (ie., your web browser cannot find a URL), you may not know whether the URL doesn't exist, or the dial-up link didn't come up.
Dialmon was originally conceived as a simple monitor to provide the Windows user with some information about the link. In its original form, it comprised a single daemon process dialmon which ran on the Linux box in parallel to daild, and a client dialm to run on the Windows client.
The dialmon daemon connected to the diald daemon using the laters control fifo, requesting that state information be retured via a second fifo which dialmon created. When dialm clients connected, the state information provided by diald, suitably filtered to remove un-needed stuff, was passed back to the dialm client, which could then display the current dial-up state. Two sorts of information were displayed, the actual link state (up, down, connecting ...) and message output generated by diald's connect and disconnect scripts.
So if, for instance, you pointed your browser at https://www.linuxgazete.com (sic) then you could see the link come up and, when the browser failed to find the URL, you hopefully realised that you should have pointed it at https://www.linuxgazette.net.
This seemed a big improvement, but there were still some more minor niggles. Firstly, the web browser would often time out a URL before the dial-up link came up (particularly in the early evening!), which meant trying the URL a second time. Of course, by this stage the dial-up link had often just gone down again on account of there being no traffic. Secondly, if you ran sendmail or similar on the Linux box and used a mail reader on the Windows client, then to get an urgent item of mail on its way from the Linux box to your ISP (or to check for incoming mail), you'd need to indulge in some trick like using your web browser simply to force the link up. Try explaining that one to your users!
So, dialmon was extended to allow control over the link Actually, these changes spanned three releases, but the effect is that users on the Windows clients, can, subject to various access controls, request that the link be brought up, request that it be taken down, and even request that diald itself be stopped and restarted with a different configuration (which appeared because I need to use two ISPs). This feature also has the side effect that if diald crashes, then dialmon will restart it.
The access control can be based either on the host on which dialm is running, or on a user name with password checking. The latter can be set up to use Linux box user names which do not have login access and which are different to the Windows user's real user name (if any) on the Linux box.
One or two users asked whether dialmon could show some load information, ie., the amount of traffic going through the dial-up link. Having done nothing myself, someone (Jim Mathews, thanks) provided some code to give an indication of this via an icon in the Win95/98/NT system tray. This has now been extended to show a pair of bars in the dialm window, one for transmit and one for receive, which show, at least approximately, the percentage of the dial-up bandwidth which is being used.
This is quite useful if you are doing a large download, to get an idea of whether it is worth carrying on, or whether you should kill the download and try later (while America sleeps, maybe).
So, how does one set all this up? The distribution (ftp://sunsite.unc.edu/pub/Linux/system/daemons/dialmon-0.4.tgz.THISONE) contains the Linux and Windows sources, plus prebuilt Win31 and Win95/98/NT clients. Once you have built and installed the Linux dialmon daemon, you need to configure it.
I'll describe the setup I use at home (which is also the office). The network comprises two Linux boxes, of which one called quaking runs diald and sendmail, plus a Windows 3.1 machine called rover which my wife Tina mainly uses, and a Windows 95 machine called gingling which I use. I want to be able to bring the dial-up link both up and down, and to switch between two ISPs, and I want to allow Tina to bring the link up and down, but not to switch ISPs.
The dialmon daemon uses two configuration files, /etc/dialmon.conf to specify its own setup, and the options to be given to client machines, and /etc/dialmon.users to specify options to be given to specific users. These are shown below:
/etc/dialmon.conf
[host] port 7002 force 90 fifo /etc/diald/diald.ctl allow up ddconf Planet "-f /etc/diald.conf.planet" ddconf Demon "-f /etc/diald.conf.demon"
This specifies that dialmon listens for dialm clients on port 7002 and will force the dial-up link up for 90 seconds (after which, if there is no traffic on the link, diald will shut it down). The allow up line specifies that any client dialm is allowed to bring the link up. The two ddconf lines specify ISP configurations; the text in "...." is the arguments to diald.
/etc/dialmon.users
[mike] passwd dialmon allow up allow down allow ctrl [tina] passwd dialmon allow up allow down
The users file specifies the access for myself and Tina. The lines passwd dialmon indicates that when mike (or tina) connects, the password supplied should be checked against that for the user dialmon rather than mike (or tina).
Lastly, the daemons run from a startup script /etc/rc.d/init.d/diald which is linked as /etc/rc.d/rc3.d/S99diald (I use the RedHat distribution which has SysV style startup scripts):
/etc/rc.d/init.d/diald
#!/bin/sh # # diald Start or stop the dialer daemon # . /etc/rc.d/init.d/functions if [ ! -f /etc/sysconfig/network ]; then exit 0 fi . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 [ -f /sbin/ifconfig ] || exit 0 # See how we were called. case "$1" in start) echo -n "Starting dialer demon: " /sbin/route del 0.0.0.0 # Start dialmon, which will in turn run diald with the Demon # configuration, and will if necessary kill off the ppp0 # PPP daemon # daemon /usr/sbin/dialmon -rDemon -pppp0 -b28800 [ -f /proc/sys/net/ipv4/ip_dynaddr ] && echo 1 > /proc/sys/net/ipv4/ip_dynaddr echo "" ;; stop) # Shut dowm. Don't use killproc because we want a SIGTERM and # not a SIGKILL, so that dialmon can terminate diald (and maybe # pppd as well). # echo -n "Shutting down dialer daemon: " [ -f /var/run/dialmon.pid ] && ( kill -TERM `cat /var/run/dialmon.pid` rm -f /var/run/dialmon.pid echo -n "dialmon " ) echo "" ;; *) echo "Usage: diald {start|stop}" exit 1 esac exit 0
The -rDemon argument to /usr/sbin/dialmon tells dialmon to initially run diald with the Demon configuration. The -ipppp0 argument says that, when dialmon restarts diald, it should kill any ppp daemon running for the ppp0 link (it looks in /var/run/ppp0.pid), and -b28000 says that the nominal link bandwidth is 28000 baud (used for the receive and transmit displays).
I've found that dialmon makes life easier for myself, and my wife (who claims to be a computerphobe but loves eMail) uses it all the time; I've also installed it on the office network of one of my clients. Quite a number of people have eMail'ed me about it (thanks for the bug reports, suggestions, contributions, not to mention the thanks) so I'd like to think that its made life a bit better for them as well.
As I mentioned above, it should be available from ftp://sunsite.unc.edu/pub/Linux/system/daemons/dialmon-0.4.tgz.THISONE (THISONE on account of an upload error, please ignore the tgz file without the extension unless it's been sorted!) Please feel free to eMail me at mike@quaking.demon.co.uk .