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.1, 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 can login does not work
----------------------------------------------

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

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:

    LOGIN=/usr/sbin/loginstub

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 short 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.
