Subject: Linux Diald FAQ
Newsgroups: comp.os.linux.answers,misc.answers,news.answers 
Summary: Answers to frequently asked questions about diald for Linux. A
         daemon that does on demand dialing for PPP and SLIP.
Keywords: diald, SLIP, PPP, dialing, dialer, Linux, faq
Organization: The TradeNET International Trade & Commerce Corp.

Archive-name: diald_faq
Authors-compilers: schenk@cs.toronto.edu ( Eric Schenk )
                   gordon@tradenet.com ( Gordon Soukoreff ) 
Last-modified: August 14th, 1995
Version: 1.06


                    ******************************************
                    The Linux Diald Frequently Asked Questions
                    ******************************************

-----------------
TABLE OF CONTENTS
-----------------

1. Introduction
  1.1.  What is diald?
  1.2.  Where can I get diald?
  1.3.  Where can I get the Linux Diald FAQ?
  1.4.  The linux-diald mailing list.
  1.5.	Reporting bugs in diald.
  1.6.  Contributing to the FAQ.
  1.7.  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?

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

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 get diald?

  The most recent release of diald is diald-0.10.tar.gz.
  The code is now in BETA release as it seems to be reasonably stable.
  It will move to GAMMA when the author runs out of features he wants to add.
  The home site is ftp://sunsite.unc.edu/pub/Linux/system/Network/serial.
  It can also be obtained from any of the sunsite mirrors.

1.3) Where can I get the Linux Diald FAQ?

  Currently the FAQ is posted to comp.os.linux.answers,
  misc.answers, and news.answers and posted to the linux-diald
  mailing list. It is also distributed with the source code for
  diald, although the FAQ may be updated more often than the source.

1.4) 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.5) Reporting bugs in diald.

  Please send bug reports, patches or suggestions for improvements to
  the author (Eric Schenk <schenk@cs.toronto.edu>).

1.6) Contributing the the FAQ.

  The keeper of the FAQ is Gordon Soukoreff <gordon@tradenet.com>.
  Submissions for the FAQ should me mailed to: diald_faq@tradenet.com.
  DO NOT mail contributions directly to Gordon!

1.7) Authorship and Copyright.

  This FAQ was written by Gordon Soukoreff <gordon@tradenet.com> and
  Eric Schenk <schenk@cs.toronto.edu>.

  Copyright 1994, 1995, The TradeNET Corporation.
  Copyright 1994, 1995, Eric Schenk.

------------------------------------------------------------------------------

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 starts forwarding 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 1.3.x release kernels, and it will probably
  work with some older 1.1.x series kernels as well. There are
  some kernels in the 1.1.x series 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.
  Diald will work with both pppd-2.1.2d and the latest beta
  pppd-2.2x releases. Be aware that the pppd-2.2x releases
  are still BETA release and the interface may change and
  break diald at any time.

  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. Note that diald takes
  up one SLIP device for every connection whether it is active or not,
  and one PPP device for every connection that is currently active.

2.3) What other software will I need to use diald?

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

  If you are planning to use ppp, then you must also have pppd.
  In addition diald expects to be able to call "ifconfig" and "route".

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

  In its default "safe" configuration 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.

  If you compile diald with the UNSAFE_ROUTING option you will eliminate
  this overhead, but at the (small) risk of having active TCP sessions lock
  up if your phone connection is broken while the session is active.
  This problem has been corrected in kernels after 1.3.13, so if
  you are running a recent 1.3.x kernel you can safely use the
  UNSAFE_ROUTING option.

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

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!

  (NOTE: Eventually diald will be rewritten to do all this with a single
   process. No promises on the release date though.)


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

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 sendmail/smail guru.

------------------------------------------------------------------------------

3) Routing Problems

3.1) Can diald do proxyarp routing?

  Diald does not directly do proxyarp (yet), but you should be able to set up
  a proxyarp entry outside of diald once it starts. The best way to do this
  would be 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.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:

  (a) 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

  (b) 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!)

  (c) 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.

   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!

4.4) The stuff I put into the ip-up script for pppd freezes. Why?

  This is a bug in 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, get the
  lastest version.

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. If these values don't match diald can't
  properly forward packets from the proxy to the physical link. To fix
  this problem check what MTU is negotiated for the ppp link using ifconfig,
  and then restart diald with a matching MTU setting.

------------------------------------------------------------------------------

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 question 6.1.
  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 question 6.1.
  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 outgoing packets.

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.

  Here's a patch to apply to tcsh:

--- tc.func.c.orig      Tue Nov 22 21:54:05 1994
+++ tc.func.c   Tue Nov 22 21:37:43 1994
@@ -1877,7 +1877,8 @@
     else {
        char *ptr, *sptr;
        char *name = utmphost();
-       if (name != NULL) {
+       /* check agains " " to catch xterm bug... */
+       if (name != NULL && strcmp(name," ") != 0) {
            /* Look for host:display.screen */
            if ((sptr = strchr(name, ':')) != NULL)
                *sptr = '\0';

  Really this should 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
 
  -- lcp-echo-interval 10 lcp-echo-failure 2

  to your diald command line 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.

  There is no equivalent functionality for slip connections.
  Adding a single option to do this for both ppp and slip connections
  is on the list of things to do.

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. With the current kernel there is no way to change the local
  IP address for an active TCP session. This will hopefully be fixed in the
  future. 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.

------------------------------------------------------------------------------
That's all folks!
------------------------------------------------------------------------------
