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