How to Turn on PPP Debugging

The next task shows how to use the pppd command to obtain debugging information.

---

Note - You only need to perform step 1 through step 3 once for each host. Thereafter, you can proceed to step 4 to turn on debugging for the host.

---

1. Create a log file to hold output from pppd.

   % touch /var/log/pppdebug

2. Add the following syslog facilities for pppd in /etc/syslog.conf.

   daemon.debug;local2.debug /var/log/pppdebug

3. Restart syslogd.

   % pkill -HUP -x syslogd

4. Turn on debugging for calls to a particular peer by using the following syntax of pppd.

   % pppd debug call peer-name

   peer-name must be the name of a file in the /etc/ppp/peers directory.

5. View the contents of the log file.

   % tail -f /var/log/pppdebug

   For an example of a log file, see Example 35-3.

Fixing Network Problems That Affect PPP Performance

If the PPP link becomes active but few hosts on the remote network are reachable, a network problem could be indicated. This section explains how to isolate and fix network problems that affect a PPP link.

How to Diagnose Network Problems

1. Become superuser on the local machine and shut down the problematic link.

2. Disable any optional protocols in the configuration files by adding the following options to your PPP configuration:

   noccp novj nopcomp noaccomp default-asyncmap

   These options provide the simplest, uncompressed PPP available. Try invoking these options as arguments to pppd on the command line. If you can reach the previously unreachable hosts, add the options in either of the following places.

   • /etc/ppp/peers/peer-name, after the call option

   • /etc/ppp/options, so that they apply globally

3. Call the remote peer with debugging turned on.

   % pppd debug call peer-name

4. Obtain verbose logs from the chat program by using the -v option of chat.

   For example, use the following format in any PPP configuration file:

   connect 'chat -v -f /etc/ppp/chatfile'

   /etc/ppp/chatfile represents the name of your chat file.

5. Try to re-create the problem by using Telnet or other applications to reach the remote hosts.

   Observe the debugging logs. If you still cannot reach remote hosts, the PPP problem might be network-related.

6. Verify that the IP addresses of the remote hosts are registered Internet addresses.

   Some organizations assign internal IP addresses that are known within the local network but cannot be routed to the Internet. If the remote hosts are within your company, you or another administrator must set up a name-to-address translation (NAT) or proxy server to reach the Internet. If the remote hosts are not within your company, you should report the problem to the remote organization.

7. Examine the routing tables.

   1. Check the routing tables on both the local machine and the peer.

   2. Check the routing tables for any routers that are in the path from the peer to the remote system and the path back to the peer.

      Ensure that the intermediate routers have not been misconfigured. Often the problem can be found in the path back to the peer.

8. (Optional)

   If the machine is a router, check the optional features.

   # ndd -set /dev/ip ip_forwarding 1

   For more information about ndd, refer to the ndd(1M) man page.

9. Check the statistics that are obtained from netstat -s and similar tools.

   For complete details on netstat, refer to the netstat(1M) man page.

   1. Run statistics on the local machine.

   2. Call the peer.

   3. Observe the new statistics that are generated by netstat -s.

   You can use the messages that are generated by netstat -s to isolate and fix the network problems that are shown in the next table.

   Table 35-2 Common Network Problems That Affect PPP

   Message	Problem	Solution
   IP packets not forwardable	The local host is missing a route.	Add the missing route to the local host's routing tables.
   ICMP input destination unreachable	The local host is missing a route.	Add the missing route to the local host's routing tables.
   ICMP time exceeded	Two routers are forwarding the same destination address to each other, causing the packet to bounce back and forth until the time-to-live (TTL) value is exceeded.	Use traceroute to find the source of the routing loop, and then contact the administrator of the router in error. For information about traceroute, refer to the traceroute(1M) man page.
   IP packets not forwardable	The local host is missing a route.	Add the missing route to the local host's routing table.
   ICMP input destination unreachable	The local host is missing a route.	Add the missing route to the local host's routing tables.

10. Check the DNS configuration.

    A faulty name service configuration causes applications to fail because IP addresses cannot be resolved.

    You can find information for fixing name service problems in "DNS Troubleshooting (Reference)" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Fixing General Communications Problems

Communications problems occur when the two peers cannot successfully establish a link. Sometimes these problems are actually negotiation problems, caused by incorrectly configured chat scripts. This section contains information for clearing communications problems. For clearing negotiation problems that are caused by a faulty chat script, see Table 35-5.

How to Diagnose and Fix Communications Problems

1. Become superuser on the local machine and call the peer.

2. Call the remote peer with debugging turned on.

   % pppd debug call peer-name

   You might need to obtain debugging information from the peer in order to fix certain communications problems.

3. Check the resulting logs for the communications problems in the next table.

   Table 35-3 General Communications Problems That Affect PPP

   Symptom	Problem	Solution
   too many Configure-Requests	One peer cannot hear the other peer.	Check for the following problems: The machine or modem might have faulty cabling. The modem configuration might have incorrect bit settings or have broken flow control. The chat script might have failed. In this situation, see Table 35-5.
   The pppd debug output shows that LCP comes up, but higher-level protocols fail or show CRC errors.	The asynchronous control character map (ACCM) is incorrectly set.	Use the default-async option to set the ACCM to the standard default of FFFFFFFF. First try using default-async as an option to pppd on the command line. If the problem clears, then add default-async to /etc/ppp/options or to /etc/ppp/peers/peer-name after the call option.
   The pppd debug output shows that IPCP comes up but terminates immediately.	IP addresses might be incorrectly configured.	Check the chat scripts to verify whether it has incorrect IP addresses. If the chat script is okay, request debug logs for the peer, and check IP addresses in the peer logs.
   The link exhibits very poor performance.	The modem might be incorrectly configured, with flow control configuration errors, modem setup errors, and incorrectly configured DTE rates.	Check the modem configuration and adjust accordingly.