The Linux Diald FAQ
by Eric Schenk, Eric.Schenk@dna.lth.se and Gordon Soukoreff.
v1.14, 28 January 1997
----------------------------------------------------------------------------
This document provides answers to frequently asked questions about Diald, a
daemon to manage on-demand connections to the Internet via SLIP and PPP
links. Portions of this document are specific to the most recent release of
diald. The most recent release of diald is version 0.16.
----------------------------------------------------------------------------
1. Introduction
* 1.1 What is diald?
* 1.2 Where can I find out more?
* 1.3 Where can I get diald?
* 1.4 Where can I get the Linux Diald FAQ?
* 1.5 The linux-diald mailing list.
* 1.6 Reporting bugs in diald.
* 1.7 Contributing the the FAQ.
* 1.8 Authorship and Copyright.
2. General Questions
* 2.1 How does diald work?
* 2.2 What kernel versions will diald work with?
* 2.3 What other software will I need to use diald?
* 2.4 Does diald introduce much overhead on the line it manages?
* 2.5 Can I get diald to share the modem with other packages?
* 2.6 Can I make diald connect at fixed times (e.g. to deliver mail)?
* 2.7 Can diald deal with a service that uses callback?
* 2.8 Can I use diald to make connections to more than one site at the
same time?
* 2.9 My connections time out before diald connects. Can I make them
wait?
* 2.10 Diald fails on reading the /etc/diald.conf line with tcp.www in
it.
* 2.11 Diald fails on reading the /etc/diald.conf line with tcp.ftp-data
in it.
* 2.12 Diald fails on reading the /etc/diald.conf line with
udp.netbios-ns in it.
* 2.13 The syslog messages generated by diald are messed up. Why?
* 2.14 Can diald help me have mail addressed to my site delivered to me?
* 2.15 Diald is dropping the first few packets when the link comes up!
Why?
* 2.16 When diald is connecting logins and su's get delayed. Why?
* 2.17 Can diald deal with incoming connections?
* 2.18 When I start diald from /etc/rc* it fails to even run. Why?
* 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?
3. Routing Problems
* 3.1 Can diald do proxyarp routing?
* 3.2 I want to route to a subnet, how can I do that?
* 3.3 I have a dynamic IP connection, and if the connection gets broken
half way through a session I can't reconnect. Is there anything I can
do?
4. PPP specific problems.
* 4.1 I started up diald in ppp mode, but it started a SLIP connection
instead of running pppd. What did I do wrong?
* 4.2 Diald starts up pppd, but pppd hangs without finishing the
connection.
* 4.3 I started up diald in ppp mode, and now I'm getting permission
errors in my system logs, and ppp won't connect.
* 4.4 The stuff I put into the /etc/ppp/ip-up script for pppd freezes.
Why?
* 4.5 I am getting messages that say ``Error forwarding data packet to
physical device: Message too long'' in my syslog, and connections
aren't working properly. Why?
* 4.6 I am getting messages that say ``Restart diald with mtu set to X to
avoid errors.'' in my syslog. Why?
* 4.7 I'm getting the message "PPP network layer died, but link did not.
Probable configuration error." in my system logs. What does it mean?
5. SLIP specific problems.
* 5.1 I'm using DIP to make the slip connection and things aren't
working.
* 5.2 Can I use the BOOTP protocol to determine my IP addresses?
6. Problems controlling the connection.
* 6.1 My connection keeps coming up, for no apparent reason.
* 6.2 Once my connection goes up it won't go down.
* 6.3 I'm having trouble making diald come up for nameserver lookups.
* 6.4 How come diald doesn't notice when my modem gets hung up on?
* 6.5 The link keeps coming up whenever I su or create a new xterm.
* 6.6 Can diald keep my connection up all the time?
* 6.7 Can I configure diald so that it won't make connections at certain
times?
* 6.8 I have really bad phone lines that freeze up. Can I get diald to
notice?
* 6.9 I use sendmail with UUCP, but sendmail is causing diald to bring up
the connection. How do I stop it?
* 6.10 When I send mail to a local site diald brings the link up. Why?
* 6.11 I'm using dynamic addresses, and the first TCP session over a line
always freezes.
----------------------------------------------------------------------------
1. Introduction
1.1 What is diald?
Diald is a daemon that does demand dialing for PPP and SLIP. The purpose of
diald is to make it transparently appear that you have a permanent
connection to a remote site. Diald sets up a ``proxy'' device which stands
in for the physical connection to a remote site. It then monitors the proxy,
waiting for packets to arrive. When interesting packets arrive it will
attempt to establish the physical link to the remote site using either SLIP
or PPP, and if it succeeds it will forward traffic from the proxy to the
physical link. As well, diald will monitor traffic once the physical link is
up, and when it has determined that the link is idle, the remote connection
is terminated. The criteria for bringing the link up and taking it down are
configurable at run time, and are based upon the type of traffic passing
over the link.
1.2 Where can I find out more?
The diald home page at http://www.dna.lth.se/~erics/diald.html provides
access to the most up to date information about diald at all times. If you
don't have access to the web, you can also just obtain the diald
distribution, which includes the documentation for diald.
Note that the address of the diald home page has recently changed!
1.3 Where can I get diald?
The most recent release of diald is version 0.16. Diald is available from
sunsite and the numerous sunsite mirrors. The URL of diald at sunsite is
ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/diald-0.16.tar.gz. The
latest version of diald can also be obtained from the diald home page at
http://www.dna.lth.se/~erics/diald.html.
1.4 Where can I get the Linux Diald FAQ?
An ASCII version of the FAQ is distributed with the source code for diald,
although the FAQ may be updated more often than the source. The latest
version of this document is always available in a number of formats from the
diald home page at http://www.dna.lth.se/~erics/diald.html.
1.5 The linux-diald mailing list.
There is a mailing list for the discussion of diald. You may subscribe by
sending a mail message with ``subscribe linux-diald'' in the body to
majordomo@vger.rutgers.edu. If you have successfully subscribed you should
get an acknowledgement. For help on the use of the mail server send a
message with ``help'' in the body to the same address.
The mailing list is being archived by Jeremy Hall jhall@isdn.net. Copies of
the archive can be obtained at ftp://rex.isdn.net/pub/diald. Currently the
archives are updated once a month.
1.6 Reporting bugs in diald.
Please send bug reports, patches or suggestions for improvements to the
author (Eric Schenk Eric.Schenk@dna.lth.se ).
1.7 Contributing the the FAQ.
Contributions for the FAQ, suggestions for improvements, and comments in
general should be sent to the primary author (Eric Schenk
Eric.Schenk@dna.lth.se ).
1.8 Authorship and Copyright.
This FAQ was written by Eric Schenk and Gordon Soukoreff.
Copyright 1994-1997 Eric Schenk. Copyright 1994, 1995, The TradeNET
Corporation.
----------------------------------------------------------------------------
2. General Questions
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.
----------------------------------------------------------------------------
3. Routing Problems
3.1 Can diald do proxyarp routing?
Yes, just like pppd, you can add the ``proxyarp'' option to your command
line or configuration file and diald will put an entry in the ARP table for
you pointing your local Ethernet at the far end of the connection. This will
work in both PPP and SLIP modes. See the man page for more information.
3.2 I want to route to a subnet, how can I do that?
Diald will do default gateway routing and point to point routing by itself,
but if you want to have diald route a specific subnet through the link it
controls you need to use the addroute option. This lets you specify the name
of a shell script to run once diald establishes its device. The script gets
passed the interface and addresses that have been established. You can then
create the proxyarp entry using this information. See the man page for more
information.
3.3 I have a dynamic IP connection, and if the connection gets broken half
way through a session I can't reconnect. Is there anything I can do?
Sorry, no. The problem is that once you establish a TCP connection to the
outside world the system on the other end thinks it knows your IP address.
If the link goes down and comes back up with a different IP address then the
system on the other end of your TCP connection can't tell you've moved. If
you want to be able to deal with this you need to get a fixed IP address for
your machine.
----------------------------------------------------------------------------
4. PPP specific problems.
4.1 I started up diald in ppp mode, but it started a SLIP connection instead
of running pppd. What did I do wrong?
Nothing. Diald doesn't start pppd until it needs to establish the physical
connection to the remote site. It does, however, always establish a SLIP
connection that it uses to monitor outgoing traffic so it can decide when to
bring up the link.
4.2 Diald starts up pppd, but pppd hangs without finishing the connection.
There might be several reasons for this. The common ones are:
1. your remote machine may expect you to tell it your IP address, (and
perhaps even it's address!). In this case you must make sure you pass
pppd an option to deal with this. e.g., end your diald options with
something like
-- 129.2.33.1:129.2.33.4
or place the line
129.2.33.1:129.2.33.4
into your /etc/ppp/options file.
2. When pppd starts up it tries to do a gethostid(). If your system is set
up in such a way as to cause this to require a name server lookup, then
pppd will lock waiting for the name server to answer. (The reasons this
doesn't happen when diald is not running is that a name server request
would find the network unreachable when diald is not running, but when
diald is running the network is reachable via diald's proxy route!) If
you are having this problem you should check the following things.
o Make sure your /etc/host.conf has the line:
order hosts,bind
and not
order bind,hosts
The second order will cause all name lookups to go off site and
this will cause diald to hang up.
o Make sure that your hostname, as reported by the command
``hostname'' is set to be only the local hostname, and not the
fully qualified domain name. That is, if your machine is
``foo.bar.com'', the hostname returned by ``hostname'' should be
``foo'' and not ``foo.bar.com''. The hostname returned by
``hostname -f'' should be ``foo.bar.com''.
o Make sure that you have a line in your /etc/hosts file for
``foo.bar.com'', and make sure the alias ``foo'' is defined on the
same line. More specifically, if your machine has the address
``196.22.11.4'', then you should have the line:
196.22.11.4 foo.bar.com foo
in your /etc/hosts file.
o Make sure your /etc/resolv.conf file correctly specifies your
domain. If your machine is ``foo.bar.com'' then your
/etc/resolv.conf file should contain the line:
domain bar.com
3. If you are using chap security, and you refer to machines by name in
your chap secrets file, pppd will attempt to ask the nameserver about
those machines. Use IP numbers instead of names in your chap secrets
file.
4.3 I started up diald in ppp mode, and now I'm getting permission errors in
my system logs, and ppp won't connect.
There are two possibilities here.
* You specified a device in your ppp options file. This conflicts with
diald, since diald starts up pppd with the tty device already open and
locked. Don't specify a device in your options file!
* You specified one of the /dev/cua* devices to diald, and you have the
serial port configured to lock out multiple opens. Pppd will then
complain that it cannot open the device. This is a bug in pppd. It
already has an open descriptor for the device, but since /dev/cua*
devices only permit one process to open them at a time, and pppd tries
to reopen the device, it fails. You can either configure the serial
port so that multiple opens are allowed (see the "setserial" manual
page), or you can patch pppd. Note that if you configure your serial
port to allow multiple opens, then you may be breaking a working getty
configuration. If you want to patch pppd then you can find patches for
both versions 2.1.2d and 2.2.0f in the patches subdirectory of the
diald distribution. You can also get the patches from the diald home
page at http://www.dna.lth.se/~erics/diald.html.
4.4 The stuff I put into the /etc/ppp/ip-up script for pppd freezes. Why?
This is a bug in old releases of pppd. The problem is that SIGALARM signals
are blocked in all children of pppd. This breaks any program that tries to
do a sleep. This was fixed in release 2.1.2d of pppd, and has never been a
problem with the 2.2.0 pppd releases. Get a more recent version of pppd.
4.5 I am getting messages that say ``Error forwarding data packet to
physical device: Message too long'' in my syslog, and connections aren't
working properly. Why?
This is a symptom of a mismatch in the MTU on the proxy link and the MTU
negotiated by pppd. See the next question for information on fixing this.
4.6 I am getting messages that say ``Restart diald with mtu set to X to
avoid errors.'' in my syslog. Why?
If you are using pppd, and pppd negotiates a value smaller than that you
asked for, then diald will attempt to adjust the mtu to the setting
negotiated by pppd. This is not guaranteed to work without causing errors,
since adjusting the mtu of an interface that is already up is not supported
by the kernel. Hopefully a future version of the kernel will support this.
In the mean time, if diald needs to change the mtu on the fly it will report
the fact that it made a change and issue the above error message. To be sure
that no problems will occur you should probably restart diald with an mtu
setting matching that reported by diald in the system logs.
4.7 I'm getting the message "PPP network layer died, but link did not.
Probable configuration error." in my system logs. What does it mean?
The PPP specification allows for the network layer to be brought up and down
multiple times within a single PPP session. Normally this never happens. It
is happening to you. The only reason that I am aware of for this is a buggy
PPP implementation on the remote side. These bugs are tickled when you are
using ppp-2.2. What happens is that your pppd is sending along a packet
asking if the other side wants to use a compression protocol. For whatever
reasons the other side doesn't know anything about compression protocols and
gets confused. The symptom is that the network layer goes up, then goes down
a few seconds later, and then comes up again. To solve this problem you must
be sure that you are not loading the bsd_comp module, and you must include
the "-bsdcomp" option in your /etc/ppp/options file.
----------------------------------------------------------------------------
5. SLIP specific problems.
5.1 I'm using DIP to make the slip connection and things aren't working.
DIP won't work together with diald. This does not mean you cannot use SLIP.
Diald does the slip code by itself. The connect script is only needed to
dial the remote site and send the appropriate commands to get it into slip
or ppp mode. It must not attempt to manipulate the line discipline on the
local end. Diald or pppd will take care of that. Get ``chat'' from the pppd
distribution and use that to establish your connections.
Now, a slightly longer explanation about the conflicts between DIP and
diald. Diald needs a program that can dial the remote site and negotiate the
connection. DIP can do this. BUT, diald has a few more requirements. First,
diald may try dial out on more than one serial line, it therefore starts up
the connection program with its standard input and output connected to the
serial line it chose. DIP cannot, as far as I can see deal with this, since
you must explicitly set the device to use in the DIP script. Second, diald
must own the controlling terminal on the serial line in order for pppd to
work correctly. This appears to conflict with DIP which also tries to get
the controlling terminal (at least in some versions of DIP). Finally, DIP
will always try to lock the serial line it opens. This conflicts with
diald's file locking.
5.2 Can I use the BOOTP protocol to determine my IP addresses?
Yes. See the ``bootp'' argument to the dslip-mode option.
----------------------------------------------------------------------------
6. Problems controlling the connection.
6.1 My connection keeps coming up, for no apparent reason.
There must be some source of packets that is forcing the link to come up. To
solve your problem you must first identify this source.
You can monitor the packets going to the link by running diald in filter
match debugging mode (option ``debug 31''). You can also also use tcpdump to
monitor the packets going over the link. You can also ask diald to dump out
the current contents of its connection queue by sending it SIGUSR2.
Once you have identified the source of packets that is causing the link to
come up, you can take action to prevent the problem. This will mean either
stopping the packets at the source, or changing the configuration of diald
to ignore the packets.
The most common sources of packets that can force the link up are the
routing daemons ``routed'' and ``gated'', and the name server daemon
``named''. (Note that the default /etc/diald.conf file is written to ignore
conversations between named servers, and to ignore traffic from routed and
gated. Unless you changed /etc/diald.conf it is unlikely these programs are
the source of packets keeping your link up.)
If you are having problems with named bringing diald up, the easiest thing
to do is to stop using named. If you absolutely must use named you should
read question 6.3 .
6.2 Once my connection goes up it won't go down.
The answer to this question is essentially the same as that for the previous
question. There must be some source of packets that is keeping the link up.
However, it may be that the source of packets that is keeping your link up
is on the remote computer. Proceed as described for the previous question.
Note that if you want to use tcpdump to monitor the packets and you are
using ppp, then you must ask tcpdump to monitor the ppp link and not the
slip proxy link, otherwise you will only see packets that pass through the
system before diald brings up the link.
6.3 I'm having trouble making diald come up for nameserver lookups.
If your site is running named and you use the distributed /etc/diald.conf
file, then you will find that diald won't bring the connection up to resolve
names that your named server doesn't know from its local data. The relevant
line in your /etc/diald.conf file is the following:
accept udp 0 udp.dest=udp.domain,udp.source=udp.domain
This line says to ignore conversations between two name servers, and
effectively prevents your name server from bringing up the link.
Several solutions have been proposed to this problem. Consult the
linux-diald archives to get the full discussion. I will propose only two
solutions here.
The first is to leave the /etc/diald.conf file alone, and specify an
alternative nameserver in your /etc/resolv.conf file. Note that you must do
this on all the machines in your local network, and that the alternative
nameserver must be external to your network. (WARNING. I've had reports that
this does not work for all sites. I do not know why. It does appear to work
for for me, but I've only run named to test this. I do not normally run
named at all.)
The second approach is to comment out the line disallowing named to named
conversations. Once you have done this you will find that diald gets brought
up at semi-random intervals. Namely whenever named decides it needs to
refresh the data in its cache. It may be that you can live with this.
If anyone can come up with a solution to this problem that works in all
cases, along with a documentable explanation of why it works, I'd like to
see it.
6.4 How come diald doesn't notice when my modem gets hung up on?
First off, you must specify the ``modem'' option to diald, or it won't even
look at the hardware signals that tell it the modem has been hung up.
Second, you must set up your modem so it toggles the DTR control line when
the carrier gets dropped. On a Hayes compatible modem include ``AT&C1&D2''
in your initialization string to accomplish this. Note that this may already
be the default on your modem, but if you are having problems you should
check this.
6.5 The link keeps coming up whenever I su or create a new xterm.
This is actually a bug in xterm that gets tickled by recent releases of
tcsh. Here's what is happening. When starting, tcsh attempts to determine a
value for the REMOTEHOST variable. It does this in two stages. First it
checks if its input file descriptor is a socket. If it is it tries to find
the other end of the socket and get its name. Second, it looks at the utmp
file in the host field. If this field is non-empty, then it tries to look up
the contents of this field as a name using gethostbyname(). Now, the problem
is, that xterm leaves `` '' in the hostname field, rather than ``''. This
causes tcsh to look up the name `` '', which of course is not in your
/etc/hosts file.
A patch to apply to tcsh can be found in the patches subdirectory of the
diald distribution in the file tcsh.patch. You can also get the patch from
the diald home page at http://www.dna.lth.se/~erics/diald.html.
Note that this problem should really be fixed in xterm, but I haven't gotten
around to doing that.
6.6 Can diald keep my connection up all the time?
Yes. Version 0.7 of diald introduced the ``up'' rule for this purpose. If
your /etc/diald.conf contains the single line:
up
the connection will be forced up at all times. See the manual page for an
explanation of the ``up'' statement.
6.7 Can I configure diald so that it won't make connections at certain
times?
Yes. You can use the time restriction rules and the ``down'' rule for this
purpose. For example, if you want to keep diald from initiating and
maintaining connections between 2 and 3 AM, you might include the following
rules at the start of your /etc/diald.conf file:
restrict 2:00:00-3:00:00 * * *
down
restrict * * * * *
The final restrict line is necessary to make the remaining lines of your
/etc/diald.conf file apply at all times. See the manual page for an
explanation of the ``restrict'' and ``down'' statements and how they affects
the filter rules in /etc/diald.conf.
WARNING: the interface of the restrict command is experimental and it may
change in future versions of diald.
6.8 I have really bad phone lines that freeze up. Can I get diald to notice?
If you are using ppp then you can use the lcp-echo-interval and
lcp-echo-failure options to manage this. For example, adding
pppd-options lcp-echo-interval 10 lcp-echo-failure 2
to your diald configure file will set up pppd so that it will attempt to
send an LCP echo-request if it has not received a packet in the last 10
seconds. If pppd sends 2 LCP echo-requests without receiving a reply, it
will terminate.
If you are using SLIP then you can use the keepalive and/or outfill options
to achieve the same effect. See the diald manual page for more information.
6.9 I use sendmail with UUCP, but sendmail is causing diald to bring up the
connection. How do I stop it?
For some reason sendmail is making domain name queries. You need to make it
stop. Consult a sendmail guru.
6.10 When I send mail to a local site diald brings the link up. Why?
Sendmail is attempting to do a name lookup on your the local hostname, and
for some reason it is not finding it in the /etc/hosts file. This is
probably a case of a misconfigured domain name. Make sure that local
hostnames do not contain the full domain name, but only the prefix. Also
make sure that the IP address being used by diald for the local host has a
defined entry in your /etc/hosts file. Configuration errors of this type can
be hard to track down. If necessary you should run sendmail with full
debugging on to see what names it is trying to look up.
6.11 I'm using dynamic addresses, and the first TCP session over a line
always freezes.
If your IP address is assigned dynamically when the connection comes up,
then any TCP session that brings the link up will still be trying to use the
IP address assigned to your machine by diald before the connection came up.
The TCP protocol does not allow for active TCP sessions that move from one
address to another. This really requires support for some kind of mobile TCP
protocol. Both you and your provider would have to cooperate for this to
work. This problem is not likely to go away in the near future. It would be
much easier to get a static address. As a work around, you should avoid make
TCP connections directly to a known IP address. This means your /etc/hosts
file must not contain the IP addresses of any machines other than your local
machine(s), and you should not be running named in such a way that it can
pick up external addresses (which as near as I can tell means you must not
run named). Also, making a connection by giving a numeric address, e.g.
telnet 123.100.2.1
will fail. The point of this exercise is to bring the diald link up with a
nameserver query rather than a TCP session start. Once the link comes up the
nameserver query will be resolved, and the TCP session will be started with
the correct (dynamically assigned) address.
----------------------------------------------------------------------------
