4. PPP specific problems.

Contents of this section

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.
   • 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.
   • 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''.
   • 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.
   • 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.loonie.net/~eschenk/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.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter