Chapter 6 Troubleshooting pppd

Scenario:

pppd dials, the modems connect, the modem data lights flash briefly, and then the log file shows 'Hangup' or 'SIGHUP.'

Solution:

Increase pppd's debug level to 2 (chat script processing) to see if any error messages are printed by the peer at startup. 'Login incorrect' indicates that the login and/or password in the calling machine's Systems file don't match those in the answering machine's passwd file. 'etc/ppp/Login:Permission denied' indicates a file protection problem with the login shell script. '/usr/etc/pppd: Permission denied' indicates that the PPP user account cannot execute the daemon, probably because the user account is not in the 'ppp' group that owns the daemon, while the daemon is mode 4750 for security reasons.

Scenario:

pppd dials out, the modems connect, the log file says 'Call succeeded,' but ps shows pppd's state to be 'connecting' until the modems disconnect about a minute later.

Solution:

Check the log file for messages indicating negotiation problems.
Increase pppd's debugging level to 2 (input framing errors). Look in the pppd.log file for warnings indicating damaged messages, such as 'Bad FCS received,' 'Frame too long,' or 'Missed ALLSTATIONS.'

Increase pppd's debugging level to 9 (show all characters read or written) to see if the peer is sending anything at all. PPP messages should initially look like 7E FF 7D 23 ... 7E. Look for corrupted characters (for example, 7F instead of FF) or other parity bit problems.

Scenario:

PPP connects, and the user can ping the other end, but cannot use telnet, rlogin, or ftp.

Solution:

Check the log file for any messages indicating negotiation problems.
Increase pppd's debugging level to 2 (input framing errors). Look in the pppd.log file for warnings indicating damaged messages, such as 'Bad FCS received,' 'Frame too long,' or 'Missed ALLSTATIONS,' 'Bad protocol,' or 'Short frame received.'

Increase pppd's debugging level to 6 (IP message summary). When telnet is started, make sure a TCP packet is sent. A TCP packet should be received in response.

Restart pppd with the novjcomp option. If this fixes the problem, then the peer may be using a buggy IPCP option negotiation algorithm. Try running pppd with the rfc1172-vj or the rfc1172-typo-vj option. If these options do not work, go back to novjcomp and complain to the vendor of the peer's implementation of PPP.

Scenario:

PPP connects and everything works, but it is slow and erratic.

Solution:

Check if your Telebit modem is using the PEP protocol. PPP over PEP is normally show and erratic.

Increase pppd's debugging level to 2 (input framing errors). Make sure that received frames are arriving undamaged and that you are not getting an excessive number of FCS errors.

Make sure that the telephone lines are relatively clean. Noisy phone lines can cause FCS or other transmission errors, or can cause V.42 or MNP error correcting protocols to retransmit excessively, or can cause the modems to retrain frequently, slowing the connection.

Make sure the serial port is not running faster than your computer can handle.

Make sure that flow control is set up properly on the modem and on the serial port to which it is connected. If you are using hardware flow control, make sure the cable connects RTS and CTS (RS-232 pins 4 and 5).

Scenario:

When the user uses telnet, ping, or some other program to attempt a connection, the modem does not start dialing and nothing is written to the log.

Solution:

Increase pppd's debugging level to 6 (IP message summary). If it now shows the packets, but says 'dial failed,' then PPP is waiting after a failed call attempt until the call retry delay timer expires. Use SIGINT to tell pppd to reset the timer, change the Systems file entry if it is set to use too long a delay, or wait until the timer expires.

Scenario:

To avoid using a separate subnet, you set up your network as described in "ARP Table Manipulation" in the section "Connecting a Host to a LAN." The remote workstations can exchange packets with everything on that LAN, but not with any hosts or networks that are reachable through a particular router.

Solution:

Some routers implement a security feature that causes them to not believe the second IP address that is claimed to be associated with a particular Ethernet address. If your remote workstation can exchange packets with all the hosts on your LAN but not with any that are reachable only through a particular router, then that router is probably skeptical of your ARP entry. This router security feature is usually configurable. If it is not configurable, you must put the remote workstations on their own subnet as described in "Separate Network" in the section "Connecting a Host to a LAN," and configure the router so that it knows that your office hub is the gateway to that subnet.

Scenario:

PPP will not connect and the log file shows 'IPCP: Received bad Configure-Reject.'

Solution:

Restart pppd with the novjcomp option. If this fixes the problem, then the peer may be using a buggy IPCP option negotiation algorithm. Try running pppd with the rfc1172-vj or the rfc1172-typo-vj option. If these options do not work, go back to novjcomp and complain to the vendor of the peer's implementation of PPP.

Scenario:

PPP will not come up, and the peer complains that it has received a request for IPCP configuration option 3.

Solution:

Restart pppd with the rfc1171-addresses option, and report a bug to the vendor of the peer's implementation of PPP. If the peer does not recognize IPCP configuration option 3, it should respond with an IPCP Configure-Reject rather than exiting altogether.

Scenario:

The PPP link comes up and carries IP traffic, but a minute later the log file shows 'LQM: LQRs: 0/5,' then 'LQM: Too many Link-Quality-Reports lost,' then pppd closes the connection.

Solution:

Restart pppd with either the echolqm or the nolqm option and report a bug to the vendor of the peer's implementation of PPP.

If the peer does not support Link Quality Monitoring, it should issue a Configure-Reject during LCP negotiations. If, even after sending an LCP Configure-Ack in response to HP-UX's PPP LCP Configure-Request containing LQM, the peer does not recognize a Link Quality Report, it should respond with a Protocol-Reject rather than not responding at all. When pppd sees the Protocol-Reject, it will fall back to using LCP Echo-Requests for its link status monitoring functions.

An LQM failure one minute after connection startup, particularly during successful user data transfers, indicates that the peer neither properly Configure-Rejected LQM during LCP negotiations, nor properly Protocol-Rejected HP-UX PPP's first LQR.

Scenario:

When the modem abruptly gets hung up, pppd does not notice.

Solution:

Make sure that the modem drops the Carrier Detect (CD), also called Data Carrier Detect (DCD), signal when the carrier is lost. On a Telebit T1600, set '&C1."

Make sure that the cable properly connects CD (RS-232 pin 8) from the modem to the serial port, and that the pppd command line does not include the ignore-cd option.

Scenario:

Shortly after the Systems chat script completes, the log file records a SIGHUP and the connection drops. But the remote modem did not actually hang up the connection and tip works correctly.

Solution:

Make sure that the modem asserts Carrier Detect (CD), also called Data Carrier Detect (DCD), signal when it is actually talking to a remote modem. On a Telebit T1600, set '&C1."

Make sure that the cable properly connects CD (RS-232 pin 8) from the modem through to the serial port. pppd does not check the state of DCD until after the Systems chat script completes, about the time that PPP negotiations begin. If the modem is not asserting DCD, or if the cable is not delivering the signal to the serial port, pppd will not be able to tell that the modem is connected. To test this, or to work around a defective cable, start pppd with the ignore-cd option.

Scenario:

pppd will not hang up the phone, even though it was started with idle 300.

Solution:

Increase pppd's debugging level to 6 (IP frame summary) and watch for logged frames that do not say '!keepup.' If you do not want those messages to keep your line active, put them in the 'keepup' filter in the Filter file ($PPPHOME/Filter by default).

Scenario:

pppd dies with a 'Fatal error: ...' or 'Fatal system error: ...' message.

Solution:

Contact your HP support representative.

Scenario:

When you telnet to test if the answering PPP account is set up correctly, you are greeted with what looks like line noise. This is the PPP Link control Protocol Configure-Request packet, but it takes a long time for pppd to give up and go away.

Solution:

The easy way to instruct the answering pppd to exit and close the connection is to type the four-character sequence of a tilde (~), followed by three control-Cs.

The '~^C^C^C' sequence only works in PPP mode, not in SLIP mode. And in PPP mode, if you specified 'passive' on the command line, '~^C^C^C' only works after receipt of a good PPP packet.

Scenario:

pppd will not dial out; the log file says 'Device is locked.'

Solution:

pppd uses lock files compatible with other programs to avoid using a device already in use by another program, and to keep other programs from interfering with devices in use by pppd. If the pppd.log file says 'Device is locked,' look for a lock file such as LCK..cua in /usr/spool/locks, /usr/spool/uucp, /usr/spool/uucp/LCK, /var/spool/locks, or wherever your system keeps tty lock files. Each lock file should contain the process ID of the owner process. If the lock file is four bytes long, the process ID is a 32-bit binary number. If the lock file is 11 bytes long, the process ID is printed in ASCII. Look in the lock file for the owner PID (use od -d for binary files and cat for ASCII lock files), and then use ps to look for the owner.

When pppd finds a lock file of zero length, it has no way of knowing the PID of the process that created it, so to be safe, it gives up trying to open the associated tty.

Scenario:

Even though UUCP is using the modem, pppd tries to use it to place an outbound call. And when pppd has an active link, UUCP tries to make an outbound call.

Solution:

The outbound 'Auto Call Unit' (ACU) names used in PPP's Devices must match the names used for similar purposes in UUCP's Devices file. For example, if your UUCP configuration knows a device as cua0, but PPP knows it as cua, each facility will be unable to discover the lock file indicating that the other is using the device.

Scenario:

With the debugging verbosity level set to 2 or more, messages appear in the log file like 'Bad FCS received,' 'Bad protocol (even), flushing frame,' 'Short frame received (3 bytes),' 'Frame too long, flushing frame,' 'Missed ALLSTATIONS, flushing frame,' or 'Missed UI, flushing frame.'

Solution:

Some of the incoming messages are getting damaged in transit. If your throughput is erratic or lower than you expect, then refer to the section on "PPP connects and everything works, but it is slow and erratic."

If you see 'Missed ALLSTATIONS' while the link is coming up, after 'Chat script succeeded' but before the first 'Received LCP configure-Request,' do not worry. The calling daemon is scanning the characters it sees coming from the answering system, looking for the start of a PPP frame that signifies the beginning of option negotiations. While the contents of the answering machine's /etc/motd scrolls by, it is likely that the calling daemon will flush several of what it had thought to be frames, but that turned out to be more text.

If the messages happen while the link is active, but only rarely, then do not worry about them. The errors may be due to intermittent line noise in the phone lines, or your computer may occasionally lose incoming characters. This last possibility is likely if the errors tend to occur when receiving large amounts of data.

Scenario:

/etc/resolv.conf points at a name server out on the Internet someplace, across the PPP link. When /etc/resolv.conf is in place and the PPP connection is up, connectivity between internal hosts is fine. When /etc/resolv.conf is in place and the PPP connection is down, connectivity between internal hosts slows down significantly. Once the /etc/resolv.conf is removed, connectivity returns to normal.

Solution:

Local applications are trying to reverse-resolve incoming connection addresses (even on the local network) into names, whether for authentication (for example, /.rhosts and /etc/hosts.equiv) or just normal operations (for example, telnetd making entries into /etc/utmp and /var/adm/wtmp). When the DNS resolve routines cannot reach the name server, they do not return a value that means "I don't know" until some timeout interval has passed. This is probably happening on every connection attempt.

Run a local name server that is either Start of Authority (SOA) or an authoritative secondary Name Server (NS) for your name space (forward mapping) and your address space (reverse mapping). An authoritative secondary NS is one that is listed in the SOA's Resource Record (RR) for that domain.

Scenario:

Using PPP on a system or network where Frame (a WYSIWYG document production system) is installed, pppd dials the modem hourly even though no users are actively using it. The pppd.log file shows a line like:

9/23-18:48:34-83 udp 192.0.2.1/3680 ->
192.0.2.2/sunrpc 45 bringup

Solution:

This is Frame's copy license manager probing for other license managers on the network. To avoid bringing up the link for this sort of packet, append '!sunrpc' to the 'bringup' filter in the Filter file.

Scenario

When PPP is used in SLIP mode, the peer receives only alternating frames. Every other frame is discarded.

Solution

The peer's SLIP implements only the optional framing style suggested in the PROTOCOL section of RFC 1055, and cannot receive adjacent frames separated by only one END character (0xC0). Add extra-slip-end to the pppd command line.