2. General Questions

Contents of this section

2.1 How does diald work?

Diald initially sets up a SLIP connection on a pseudo terminal and sets up routing to the slip connection. This connection is called the ``proxy''. This trick fools the kernel into thinking that it has a network connection that is not really there. Anything sent over the proxy connection is encoded into the SLIP protocol and appears on the master side of the pseudo terminal. Now, diald sits around reading the master side of the pseudo terminal. When it sees packets coming over the line it decodes them into IP packets and decides if it should bring up the actual physical link, which can be either SLIP or PPP. Once it brings up the physical link it routes packets from the proxy to the physical link, and monitoring traffic to keep control of the line.

(Note: the above is not intended to be a complete description of how diald works. It is just a sketch for the curious.)

2.2 What kernel versions will diald work with?

Diald was initially written on the 1.1.x series of kernels. It is known to work with most kernels from 1.1.56 up through to the latest 2.1.x release kernels, and it will probably work with some older 1.1.x series kernels as well. There are some kernels in the various development series kernels under which diald cannot be compiled because the include files got munged up. If you can't compile diald get a more recent version of the kernel. Also, there are some versions of the 1.3.x series which have various other problems. If you have trouble you should consider upgrading to a 2.0.X kernel or perhaps a 2.1.X kernel if you want to live on the edge.

Diald will NOT work properly with kernels in the 1.0.x series. Sorry, but the kernel doesn't provide all of the services required by diald.

You must have SLIP devices in your kernel in order to use diald, EVEN IF YOU PLAN TO USE ONLY PPP CONNECTIONS! Let me repeat that, diald needs SLIP to work under all circumstances. It uses a SLIP link on a pseudo terminal to create the proxy device that stands in for the real connection. Naturally, if you plan on using diald to establish PPP connections, you must also have PPP devices in your kernel.

Also, if you plan to have a lot of diald's running around (connecting to different sites) you will probably need to increase the number of SLIP and possibly PPP devices in your kernel (Unless you are using a kernel with dynamic allocation of SLIP and PPP devices. The driver for pppd-2.2.0 introduces this for ppp devices. 1.3.X series kernels have it for slip devices as well.) Note that diald takes up one SLIP device for every connection whether it is active or not, and one SLIP or PPP device for every connection that is currently active. This means that in SLIP mode a running copy of diald will use two SLIP interfaces when the link is up.

2.3 What other software will I need to use diald?

If you expect to use PPP connections, the you will need pppd. Diald will work with any version of pppd from 2.1.2d through the current 2.3beta releases.

You must also have a program like ``chat'' or ``expect'' to do dialing. Diald doesn't particularly care what program does the dialing, but the dialing program must be able to do its job using only the standard input and output. This means you can't use most version of dip. Sorry.

In addition diald expects to be able to call ``ifconfig'' and ``route''.

2.4 Does diald introduce much overhead on the line it manages?

Normally diald will not introduce any delay into the path for outgoing packets.

If for some reason you must run diald without the ``reroute'' option turned on, then diald reduces the throughput of outgoing packets by about 10-20%. This is because every outgoing packet must be copied from the proxy interface to the physical interface. There is no reduction in throughput for incoming packets.

In older kernels (before version 1.3.13) running diald with the ``reroute'' introduces the (small) risk of having active TCP sessions lock up if your phone connection is broken while the session is active. This problem cannot occur if you never have more than one copy of ``pppd'' running.

2.5 Can I get diald to share the modem with other packages?

Yes, as long as you are using the same device name in all the programs you use to access the modem, and all the programs use UUCP style lock files. Note that diald does not use lock files by default. You must request lock files with the ``lock'' option. Also note that you must make sure diald knows where your other applications put lock files, and that it uses the same type of lock files. This must be configured at compile time.

2.6 Can I make diald connect at fixed times (e.g. to deliver mail)?

Sure. Just have a cron job start the job. Diald should try to connect as usual. One possible problem is that your job may timeout waiting for the connection to be established. You should either arrange it so that the job gets tried again if it fails to connect, or you should lengthen the timeout parameters for TCP connections (see question 2.9 ).

2.7 Can diald deal with a service that uses callback?

Yes. This is a problem for your connection script to deal with. I know of people that have used chat for this purpose, but if you are having trouble doing this with chat you should probably consider using expect to write your connection script.

2.8 Can I use diald to make connections to more than one site at the same time?

Yes. You can run multiple copies of diald simultaneously. Each site you want to connect to should be managed by a diald process. Each diald is configured independently. The only difficulty is that you must be sure that the routing for the two sites does not conflict. The main point here is that only one site can be the default gateway for traffic!

2.9 My connections time out before diald connects. Can I make them wait?

There are two parameters you may want to slow down.

First, you probably want to make nameserver lookups take longer. This can be done by duplicating the ``nameserver'' line in your /etc/resolv.conf file. My /etc/resolve.conf file contains three identical nameserver lines, thus tripling the timeout. Note that any more than three such lines will be ignored.

Second, if after lengthening nameserver timeouts you are still having problems, then you probably want increase the timeout for starting new TCP connections. This can be done by increasing the value of TCP_SYN_RETRIES in net/inet/tcp.h, and recompiling the kernel. Note that increasing this value by one will double the timeout.

If after recompiling the kernel the timeouts don't seem to have changed you might check to be sure that you running the new kernel. (I know, none of you will ever make that mistake. Just covering all the bases).

2.10 Diald fails on reading the /etc/diald.conf line with tcp.www in it.

Your /etc/services file doesn't define www services. Either get a newer /etc/services file or add the following two lines to your file:

www-http         80/tcp    www http     # World Wide Web HTTP
www-http         80/udp    www http     # World Wide Web HTTP
If you want to get a newer /etc/services file then I suggest getting the latest NetKit-A. I usually grab it from ftp://nic.funet.fi/pub/OS/Linux/PEOPLE/Linus/net-source/base If you really want to be up to date, find the latest RFC describing /etc/services and build your /etc/services file with the information in that document. Then contribute it back to the netkit release so that it gets updated.

2.11 Diald fails on reading the /etc/diald.conf line with tcp.ftp-data in it.

Your /etc/services file doesn't define the ftp-data service. Add the following line to your /etc/services file:

ftp-data        20/tcp
If this really annoys you get the NetKit-A maintainer to include it in the next NetKit-A release.

2.12 Diald fails on reading the /etc/diald.conf line with udp.netbios-ns in it.

Your /etc/services file doesn't define netbios services. Get a new /etc/services file, or add the following two lines to your /etc/services file (See question 2.9 for information on obtaining a new /etc/services file.)

netbios-ns      137/tcp                         # NETBIOS Name Service
netbios-ns      137/udp

2.13 The syslog messages generated by diald are messed up. Why?

In full debugging mode (option ``debug 31'') diald can output a lot of traffic to the system logger. Some implementations of syslog don't seem to be able to cope with this. I am currently using sysklogd and I don't have these problems, but I have seen them with some other implementations. If you are having this problem consider replacing your current syslog with the latest sysklogd implementation.

2.14 Can diald help me have mail addressed to my site delivered to me?

You need to set up a cron job that tries to fetch mail regularly. Consult a mail guru.

2.15 Diald is dropping the first few packets when the link comes up! Why?

You must be runing diald with the buffer-packets option turned off. Turn this option on if you don't want to drop packets (it is on by default). Note that if you are using diald with a dynamic IP address, then you might as well leave the buffer-packets option off, since any packets sent before the address gets changed can't be replied to anyway.

2.16 When diald is connecting logins and su's get delayed. Why?

This turns out to be due to a bug in sysklogd version 1.2. Upgrading to release 1.3 or newer of sysklogd will fix this problem.

2.17 Can diald deal with incoming connections?

Yes. The FIFO command pipe has the ``connect'' command for exactly this purpose. Look in the contrib directory of the diald distribution for the script diald-login. This is an example script of how to have incoming connections connect to diald.

Note that the ``two-way'' option may be necessary to avoid synchronization problems if you are attempting to set up a demand dialed connection that can be started from either end of the link. See the manual page for more information.

2.18 When I start diald from /etc/rc* it fails to even run. Why?

If you start up diald in the background, e.g. with a line like

diald &
The diald may not manage to finish setting up its signal handlers before the /etc/rc* scripts exit. In this case diald will get a SIGHUP and die before you even get started. Make sure that you run diald in the foreground, e.g.
diald
Diald will put itself into the background when it is ready.

2.19 When I start diald from /etc/rc* it starts Ok, but can't make connections. It works fine when I start diald from the command line. Why?

When you start diald from the command line the PATH environment variable is set. When you start diald from /etc/rc* it is empty. If your connect script attempts to run any programs without giving a fully qualified path, then your connect script will fail. For example:

connect "chat -v -f /etc/chatfile"
will not work, but
connect "/usr/sbin/chat -v -f /etc/chatfile"
will, assuming that chat really is in /usr/sbin.


Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter