diald-control - how to control a running copy of diald

Any running diald process.

A running copy of diald can be controlled externally in two ways. The simplest way is to send it signals. This is, by necessity, somewhat limited. If it is necessary to send more complex commands to diald the fifo or tcpport commands can be used.

Diald can be controlled by the following signals.

SIGINT

Force the link down. Diald continues to run.

SIGTERM

Shut down the link and terminate diald.

SIGUSR1

Force the link up. This will not keep the link up beyond the time that diald normally waits for the first packet to cross a link once it goes up. If you want to force the link up and keep it up you must use the "force" fifo command described below.

SIGUSR2

Dump the filter queue to the system logs.

If the fifo command is used, then additional commands can be issued to diald as follows. Suppose the command "fifo /var/run/diald/diald.fifo" is specified in diald's configuration. Then programs can write the commands to the named pipe /var/run/diald/diald.fifo, which will then be acted upon by diald. Note that diald will create the named pipe if it does not exist.

The tcpport is similar but tells diald to listen on a given port for TCP connections. Connections may made to the specified port by remote systems in order to issue commands to diald or monitor its status. If diald has been compiled with tcp wrapper support connections via TCP are accepted under control of rules for diald in /etc/hosts.allow.

Diald may be configured to listen on a fifo and a TCP port simultaneously.

The following commands may be sent to diald via the fifo or TCP port:

auth <method> <string>...

Authenticate this connection using the giving method and the given strings. This changes the set of commands which will be allowed on the connection. This command is only available on TCP connections. If <method> is "simple" then a single following string specifies the name of the privileges to request. If <method> is "pam" then the two following strings specify the UNIX username and password to be authenticated using PAM (Pluggable Authentication Modules). Privileges are then given according to group membership.

block

Block diald from making outgoing calls until a unblock command is issued. If the link is up it will be taken down immediately.

unblock

Remove a block on diald making outgoing calls.

demand

The link will be brought up as necessary when packets are sent through it.

nodemand

The link will only be brought up if manually requested using the "up" command.

force

Force diald to bring the link up until an unforce command is issued.

unforce

Remove a request for diald to keep the link forced up.

down

Force the link down. This is a one shot operation. The next packet to come along that puts an entry in the connection queue will bring the link up again.

up

Force the link up. This is a one shot operation. If no packets cross the link within the standard initial timeout the link will go back down.

debug <flags> Set the debug flags to the given value. See the diald manual page for a description of the possible values.

delay-quit

Terminate diald as soon as the link next goes idle.

quit

Force the link down and terminate diald.

reset

This will cause diald reset its configuration commands to the default values and then reread its configuration files as well as reprocess any command line arguments it might have been given. This allows on the fly changes in the configuration of a running copy of diald. WARNING: if your new configuration has errors the reset command may cause diald to terminate with an error condition.

dynamic <local-ip> <remote-ip>

Tell diald what the dynamic IP addresses are. This will only have an effect if it is received by diald during the execution of a connect script, and diald is in a SLIP mode. It is intended for use with connect scripts that do some extra work to figure out the dynamic ip addresses, so they can pass that information back to diald. This will be most useful to you if you must parse out the IP addresses and then still issue a further command as part of your login sequence. (Note that cases like this cannot be handled by the "dslip-mode" command.) Receipt of this command during a given connection attempt will turn off diald's use of mechanisms to acquire the dynamic IP addresses.

queue

Print the contents of the filter queue to the syslog.

monitor [<file>]

Ask diald to dump monitoring information to the named pipe. This is intended to be used by a separate interactive monitoring program. If <file> is not a named pipe diald will refuse to start monitoring. Diald will stop issuing monitor information on the specified named pipe when the far end of the pipe is closed. Note that there can be more than one monitor command active at the same time. The diald-monitor manual page describes the output format of the information that diald writes to the named pipe.

message <string>

Ask diald to pass <string> on to the monitoring process.

connect <pid> <device>

If diald is not currently up, then force it to come up and make a connection on the specified device. Diald will open the named device, ignoring the device specified on the diald command line, skip running the "connect" script, and attempt to run either SLIP or PPP directly. This is intended to be used to rendezvous with incoming calls. When diald closes the connection to <device> it will send SIGKILL to <pid>. Normally this will be the program that issued the connect command to diald, which will be waiting to be killed to terminate a login.

diald(8), dctrl(1), diald-monitor(5), diald-examples(5)

Eric Schenk (Eric.Schenk@dna.lth.se)