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.

  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.

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