Chapter 35 Fixing Common Problems (Tasks)

This chapter contains information for diagnosing and troubleshooting common problems that occur with Solaris PPP 4.0. The following topics are covered:

• Tools for Troubleshooting PPP

• Fixing Network Problems That Affect PPP Performance

• Fixing General Communications Problems

• Fixing PPP Configuration Problems

• Fixing Modem-Related Problems

• Fixing Chat Script-Related Problems

• Fixing Serial Line Speed Problems

• Fixing Leased-Line Problems

• Diagnosing and Fixing Authentication Problems

• Diagnosing and Fixing PPPoE Problems

The sources PPP Design, Implementation, and Debugging by James Carlson and the Australian National University's web site also have detailed advice for PPP troubleshooting. For more information, see Professional Reference Books About PPP and Web Sites About PPP.

Solving PPP Problems (Task Map)

Use the following task map to quickly access advice and solutions for common PPP problems.

Tools for Troubleshooting PPP

PPP links generally have three major areas of failure:

• Failure of the link to be established

• Poor performance of the link as it is used

• Problems that can be traced to the networks on either side of the link

This section explains how to obtain diagnostic information from pppd and its associated log files. The remaining sections in this chapter describe common problems with PPP that you can discover and fix with the aid of the PPP troubleshooting tools.

How to Obtain Diagnostic Information From pppd

The next procedure shows how to view the current operation of a link on the local machine.

1. Become superuser on the local machine.

2. Run pppd with the serial device configured for PPP as the argument:

   # pppd /dev/ttyname debug updetach

   The next examples show the resulting displays for a dial-up link and a leased-line link when pppd runs in the foreground. If you run pppd debug in the background, the output produced is sent to the /etc/ppp/connect-errors file.

   ---

   Example 35–1 Output From a Properly Operating Dial-up Link

   
   

   # pppd /dev/cua/b debug updetach have route to 0.0.0.0/0.0.0.0 via 172.21.0.4 serial speed set to 230400 bps Using interface sppp0 Connect: sppp0 <--> /dev/cua/b sent [LCP ConfReq id=0x7b <asyncmap 0x0> <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP Ident id=0x79 magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>] sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)" sent [LCP ConfReq id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP Ident id=0x7e magic=0x73e981c8 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)"] sent [IPCP ConfReq id=0x3d <addr 0.0.0.0> <compress VJ 0f 01>] rcvd [LCP Ident id=0x7a magic=0xdd4ad820 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [IPCP ConfReq id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> sent [IPCP ConfAck id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> rcvd [IPCP ConfNak id=0x3d <addr 10.0.0.2>]] sent [IPCP ConfReq id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] rcvd [IPCP ConfAck id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1

   ---

   ---

   Example 35–2 Output From a Properly Operating Leased-Line Link

   
   

   # pppd /dev/se_hdlc1 default-asyncmap debug updetach pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2001 07:13:18) started by root, uid 0 synchronous speed appears to be 0 bps init option: '/etc/ppp/peers/syncinit.sh' started (pid 105122) Serial port initialized. synchronous speed appears to be 64000 bps Using interface sppp0 Connect: sppp0 <--> /dev/se_hdlc1 sent [LCP ConfReq id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfAck id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP Ident id=0xea magic=0x474283c6 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] sent [IPCP ConfReq id=0xf7 <addr 0.0.0.0> <compress VJ Of o1>]] sent [CCP ConfReq id=0x3f <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [LCP Ident id=0x23 magic=0x8e3a53ff "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44) rcvd [IPCP ConfReq id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] sent [IPCP ConfAck id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] rcvd [CCP ConfReq id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] sent [CCP ConfAck id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] rcvd [IPCP ConfNak id=0xf8 <addr 10.0.0.2>] rcvd [IPCP ConfReq id=0xf7 <addr 10.0.0.2> <compress VJ Of 01>] rcvd [CCP ConfAck id=0x3f <deflate 15> <deflate(old#) 15 <bsd v1 15>] Deflate (15) compression enabled rcvd [IPCP ConfAck id=0xf8 <addr 10.0.0.2> <compress VJ Of 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1

   ---

How to Turn on PPP Debugging

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

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.

Fixing PPP Configuration Problems

Some PPP problems can be traced to problems in the PPP configuration files. This section contains information for isolating and fixing general configuration problems.

How to Diagnose Problems With the PPP Configuration

1. Become superuser on the local machine.

2. Call the remote peer with debugging turned on.

   % pppd debug call peer-name

3. Check the resulting log for the configuration problems that are listed in the next table.

   Table 35–4 Common PPP Configuration Problems

   Symptom	Problem	Solution
   pppd debug output contains the error message “Could not determine remote IP address.”	The /etc/ppp/peers/peer-name file does not have an IP address for the peer. The peer does not provide an IP address for itself during link negotiation.	Supply an IP address for the peer on the pppd command line or in /etc/ppp/peers/peer-name by using the following format: :10.0.0.10
   pppd debug output shows that CCP data compression has failed and the link is dropped.	The peers' PPP compression configurations may be in conflict.	Disable CCP compression by adding the noccp option to /etc/ppp/options on one of the peers.

Fixing Modem-Related Problems

Modems can be major problem areas for a dial-up link. The most common indicator of problems with the modem configuration is no response from the peer. But it is often difficult to determine if a link problem is indeed the result of modem configuration problems.

For basic modem troubleshooting suggestions, refer to “Troubleshooting Terminal and Modem Problems” in System Administration Guide: Advanced Administration. Modem manufacturers' documentation and web sites also contain solutions for problems with their particular equipment. This section contains more suggestions for isolating and fixing modem problems.

How to Diagnose Modem Problems

The following steps help determine whether a faulty modem configuration causes link problems.

1. Call the peer with debugging turned on, as explained in How to Turn on PPP Debugging.

2. Display the resulting /var/log/pppdebug log.

   Either of the following symptoms in the output can indicate a faulty modem configuration:

   • No “recvd” messages have come from the peer.

   • The output contains LCP messages from the peer, but the link fails with too many LCP Configure Requests messages sent by the local machine.

     These messages indicate that the local machine can hear the peer, but the peer cannot hear the local machine.

   • The link terminates with a SIGHUP signal.

3. Use ping to send packets of various sizes over the link.

   For complete details about ping, refer to the ping(1M) man page.

   If small packets are received, but larger packets are dropped, modem problems are indicated.

4. Check for errors on interface sppp0:

   % netstat -ni Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 127.0.0.0 127.0.0.1 826808 0 826808 0 0 0 hme0 1500 172.21.0.0 172.21.3.228 13800032 0 1648464 0 0 0 sppp0 1500 10.0.0.2 10.0.0.1 210 0 128 0 0 0

   If interface errors increase over time, this can indicate problems with the modem configuration.

Fixing Chat Script-Related Problems

Chat scripts are trouble-prone areas for dial-up links. This section contains a procedure for obtaining debugging information from chat and suggestions for clearing common problems.

How to Obtain Debugging Information for Chat Scripts

1. Become superuser on the dial-out machine.

2. Edit the /etc/ppp/peers/peer-name file for the peer to be called.

3. Add -v as an argument to the chat command that is specified in connect option.

   connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name"

4. View chat script errors in the file /etc/ppp/connect-errors.

   The following is the main error that is seen with chat.

   Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT) Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed

   The example shows timeout while waiting for a (CONNECT)string. When chat fails, you get the following message from pppd:

   Connect script failed

The next table lists common chat script errors and suggestions for fixing them.

ogin: user-name
ssword: password

ogin: pppuser
ssword: \q\U

ogin: pppuser
ssword: \q\U

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

Fixing Serial Line Speed Problems

Dial-in servers can experience problems because of to conflicting speed settings. The next procedure helps you isolate the cause of the link problem to conflicting serial-line speeds.

The following are typical causes for speed problems:

• You invoked PPP through a program such as /bin/login and specified the speed of the line.

• You started PPP from mgetty and accidentally supplied the bit rate.

How to Diagnose and Fix Serial Line Speed Problems

1. Log in to the dial-in server and call the peer with debugging turned on.

   If you need instructions, see How to Turn on PPP Debugging.

2. Display the resulting /var/log/pppdebug log.

   Check the output for the following message:

   LCP too many configure requests

   This message indicates that the speeds of serial lines that were configured for PPP might potentially be in conflict.

3. Check if PPP is invoked through a program such as /bin/login and the line speed that was set.

   In such a situation, pppd changes the originally configured line speed to the speed that is specified in /bin/login.

4. Check if a user started PPP from the mgetty command and accidentally specified a bit rate.

   This action also causes conflicting serial-line speeds.

5. Fix the conflicting serial-line speed problem as follows:

   1. Lock the DTE rate on the modem.

   2. Do not use autobaud.

   3. Do not change the line speed after it has been configured.

Fixing Leased-Line Problems

The most common problem with leased lines is poor performance. In most situations, you need to work with the telephone company to fix the problem.

Diagnosing and Fixing Authentication Problems

Diagnosing and Fixing PPPoE Problems

You can use PPP and standard UNIX utilities to identify problems with PPPoE. This section explains how to obtain debugging information for PPPoE and fix PPPoE-related problems.

How to Obtain Diagnostic Information for PPPoE

When you experience problems on the link and suspect PPPoE is the cause, use the following diagnostic tools to obtain troubleshooting information.

1. Become superuser on the machine that runs the PPPoE tunnel, either PPPoE client or PPPoE access server.

2. Turn on debugging, as explained in the procedure How to Turn on PPP Debugging.

3. View the contents of the log file /var/log/pppdebug.

   The following example shows part of a log file that was generated for a link with a PPPoE tunnel.

   ---

   Example 35–3 Log File for a Link With a PPPoE Tunnel

   
   

   Sep 6 16:28:45 enyo pppd[100563]: [ID 702911 daemon.info] Plugin pppoe.so loaded. Sep 6 16:28:45 enyo pppd[100563]: [ID 860527 daemon.notice] pppd 2.4.0b1 (Sun Microsystems, Inc., Sep 5 2001 10:42:05) started by troot, uid 0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Serial connection established. Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Using interface sppp0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.notice] Connect: sppp0 <--> /dev/sppptun Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/pap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/chap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] sent [LCP ConfReq id=0xef <mru 1492> asyncmap 0x0 <magic 0x77d3e953><pcomp><acomp> Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] rcvd [LCP ConfReq id=0x2a <mru 1402> asyncmap 0x0 <magic 0x9985f048><pcomp><acomp

   ---

   If the debugging output does not help you isolate the problem, continue on with this procedure.

4. Get diagnostic messages from PPPoE.

   # pppd connect "/usr/lib/inet/pppoec -v interface-name"

   pppoec sends diagnostic information to the stderr. If you run pppd in the foreground, the output appears on the screen. If pppd runs in the background, the output is sent to /etc/ppp/connect-errors.

   The next example shows the messages that are generated as the PPPoE tunnel is negotiated.

   ---

   Example 35–4 PPPoE Diagnostic Messages

   
   

   Connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) /usr/lib/inet/pppoec: PPPoE Event Open (1) in state Dead (0): action SendPADI (2) /usr/lib/inet/pppoec: Sending PADI to ff:ff:ff:ff:ff:ff: 18 bytes /usr/lib/inet/pppoec: PPPoE State change Dead (0) -> InitSent (1) /usr/lib/inet/pppoec: Received Active Discovery Offer from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADO+ (5) in state InitSent (1): action SendPADR+ (5) /usr/lib/inet/pppoec: Sending PADR to 8:0:20:cd:c1:2: 22 bytes /usr/lib/inet/pppoec: PPPoE State change InitSent (1) -> ReqSent (3) /usr/lib/inet/pppoec: Received Active Discovery Session-confirmation from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADS (7) in state ReqSent (3): action Open (7) /usr/lib/inet/pppoec: Connection open; session 0002 on hme0:pppoe /usr/lib/inet/pppoec: PPPoE State change ReqSent (3) -> Convers (4) /usr/lib/inet/pppoec: connected

   ---

   If the diagnostic messages do not help you isolate the problem, continue on with this procedure.

5. Run snoop and save the trace to a file.

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

   # snoop -o pppoe-trace-file

6. View the snoop trace file.

   # snoop -i pppoe-trace-file -v pppoe

   ---

   Example 35–5 PPPoE snoop trace

   
   

   ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 1 arrived at 6:35:2.77 ETHER: Packet size = 32 bytes ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast) ETHER: Source = 8:0:20:78:f3:7c, Sun ETHER: Ethertype = 8863 (PPPoE Discovery) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 9 (Active Discovery Initiation) PPPoE: Session Id = 0 PPPoE: Length = 12 bytes PPPoE: PPPoE: ----- Service-Name ----- PPPoE: Tag Type = 257 PPPoE: Tag Length = 0 bytes PPPoE: PPPoE: ----- Host-Uniq ----- PPPoE: Tag Type = 259 PPPoE: Tag Length = 4 bytes PPPoE: Data = Ox00000002 PPPoE: . . . ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 5 arrived at 6:35:2.87 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:78:f3:7c, Sun) ETHER: Source = 0:2:fd:39:7f:7, ETHER: Ethertype = 8864 (PPPoE Session) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 0 (PPPoE Session) PPPoE: Session Id = 24383 PPPoE: Length = 20 bytes PPPoE: PPP: ----- Point-to-Point Protocol ----- PPP: PPP-LCP: ----- Link Control Protocol ----- PPP-LCP: PPP-LCP: Code = 1 (Configure Request) PPP-LCP: Identifier = 80 PPP-LCP: Length = 18

   ---