The DialMon FAQ

I guess that every good piece of software should have an FAQ. So, please consider either that (a) this file is a conceit on the author's behalf, (b) is makes dialmon into a good piece of software, or (c) anything else.

1. Trouble building dialmon

1.1 The compiler complains about things like FD_SET

I am using RedHat 5.2 , which by default uses the glibc2 (aka libc6) library. I think I have enough #include's to keep libc5 systems (such as RedHat 4.2) happy, but then again I may not. If not then you need to figure out which headers to add; if you do, please let me know.

1.2 The linker grumbles that -lcrypt cannot be found

Again, this is a glibc2/libc5 artefact relating to the stupid rules about exporting cryptograpic code. The fix is either (a) to remove the -lcrypt from the Makefile and try again, (b) peacefully lobby for the rules to be changed or (c) bomb the b******s.

2. Running dialmon

2.1 When I run dialmon there is a dialnsl process, what is it?

dialmon forks a child process to do reverse name lookup (IP address to host name mapping) so that the main bit does not hang waiting for nameserver replies. It sends requests to the child down a pipe and later gets replies via another pipe. The child process does some magic with the command line so that ps(1) sees it as dialnsl (for DIALmon Name Server Lookup).

2.2 DialMon runs but I login does not work

dialmon attempts to use PAM, shadow or normal password checking depending on whether the /etc/pam.d or /etc/shadow exists or not. However, the -A, -S and -P command-line options allow you to force it to use one or the other.

2.3 How does the password stuff work

This is a bit of a fudge, intended so that you can set a password for a particular user which is not the user's real login password on the Linux box. It is then fairly safe for the client to store the password in plain-text on the client machine.

To do this, you can set something like passwd dialmon for a user fred in the /etc/dialmon.users file. What this means is that, when a client attempts to log in to the dialmon daemon with username fred, then the supplied password is checked against a user dialmon rather than fred. The dialmon user can be configured not to have a login shell, and so forth; if the password gets escapes then it only affects dialmon access, and not fred directly.

3. Multiple Configurations

3.1 I'm using multiple configurations and I get lots of diald's

You have probably run diald without the -daemon option. Without this, about the first thing it does is to fork; the parent then terminates. dialmon will think that diald has died, and will restart it. This will repeat ad nauseam.

If the configuration invokes a script rather than directly running diald, then the script should not terminate until diald does. Again, use the -daemon option. Also, assuming that the last thing that the script does is to fire up diald, the best thing is probably to exec it. This means that you don't get a wasted shell left running.

4. Monitoring Incoming Calls

A serial port with an attached modem can be set up to handle both outgoing and incoming calls. This section describes a way to set this up so that dialmon clients display whether there is an extant incoming call, in which case diald cannot dial out. Note that this works with the 2.0.x kernels; I have not yet tried this with the 2.2.x kernels where the cuaX devices are deprecated.

You need add the following things, assuming that gettystub and loginstub are both installed in /usr/sbin. Also, change devices, baud rates and so forth according to taste:

(a) /etc/inittab The line below causes init(8) to fire up the gettystub program. This pauses a while (30 seconds, needed to get round a locking bug in some versions of diald), and then exec's /sbin/getty on /dev/ttyS3 at 19200 baud (fixed). Along the way, it informs dialmon that there is no incoming call.

du:2345:respawn:/usr/sbin/gettystub -t30 -- ttyS3 F19200

(b) /etc/conf.getty.ttyS3 This file is read by getty when it starts. Along with whatever other stuff you need to configure your modem to accept incoming calls, add following line. This causes getty to invoke /usr/sbin/loginstub rather than /bin/login:

When an incoming call arrives, getty will output the login prompt and read the user name, and then invokes /usr/sbin/loginstub. This will invoke /bin/login, but, before doing so, informs dialmon that there is an incoming call.

There is a window between the incoming call being accepted, and the user entering their name, when dialmon does not know about the call, but this should be quite short.

5. Client Configuration

5.1 Can configurations move with users amongst client machines

If you mean Windows clients, then the answer is yes. The windows client can be invoked so as to get its configuration from a network server rather than from a local file. The one requirement is that you have Samba running on a Linux box, presumably the same one as the dialmon daemon. Actually, it might work with an NT server instead of Samba, but I haven't got this (nor do I intend to!). See the file NETWORK for details.

6. Running the Client

6.1 The homepage shows a drop box with Demon, but I don't see it

This drop down box only shows if you have configured the dialmon daemon to run diald as a child process, and there are multiple configurations (ie., ways to invoke diald).

The DialMon home page
Mike Richardson's Home Page