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 .
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.
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
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.
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.
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.loonie.net/~eschenk/diald.html.
Note that this problem should really be fixed in xterm, but I haven't gotten around to doing that.
Yes. Version 0.7 of diald introduced the ``up'' rule for this purpose. If your /etc/diald.conf contains the single line:
up
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 * * * * *
/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.
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
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.
For some reason sendmail is making domain name queries. You need to make it stop. Consult a sendmail guru.
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.
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
Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter