Solving PPP-Related and PPPoE-Related Problems

Refer to the following sections for information about how to resolve PPP-related and PPPoE-related problems.

How to Diagnose Network Problems
Common Network Problems That Affect PPP
How to Diagnose and Fix Communications Problems
General Communications Problems That Affect PPP
How to Diagnose Problems With the PPP Configuration
Common PPP Configuration Problems
How to Diagnose Modem Problems
How to Obtain Debugging Information for Chat Scripts
Common Chat Script Problems
How to Diagnose and Fix Serial-Line Speed Problems
How to Obtain Diagnostic Information for PPPoE

How to Diagnose Network Problems

If the PPP link becomes active but few hosts on the remote network are reachable, a network problem could be indicated. The following procedure shows you how to isolate and fix network problems that affect a PPP link.

Become superuser on the local machine or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Shut down the problematic link.
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 that is available. Try to invoke 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, ensuring that the options apply globally
Call the remote peer. Then enable debugging features.
```
% pppd debug call peer-name
```
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.
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.
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 must set up a name-to-address translation (NAT) server 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.
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. Also check the routing tables for any routers on 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.
(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.
In the Solaris 10 release, you can use routeadm(1M), instead of ndd(1M).
```
# routeadm -e ipv4-forwarding -u
```
Note - The ndd command is not persistent. The values set with this command are lost when the system is rebooted. The routeadm command is persistent. The values set with this command are maintained after the system is rebooted.
Check the statistics that are obtained from netstat -s and similar tools.
For complete details about 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. For more information, refer to Common Network Problems That Affect PPP.
Check the DNS configuration.
A faulty name service configuration causes applications to fail because IP addresses cannot be resolved.

Common Network Problems That Affect PPP

You can use the messages that are generated by netstat -s to fix the network problems that are shown in the following table. For related procedural information, refer to How to Diagnose Network Problems.

Table 21-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.

How to Diagnose and Fix Communications Problems

Communications problems occur when the two peers cannot successfully establish a link. Sometimes these problems are actually negotiation problems that are caused by incorrectly configured chat scripts. The following procedure shows you how to clear communication problems. For clearing negotiation problems that are caused by a faulty chat script, see Table 21-5.

Become superuser on the local machine or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration
Call the peer.
Call the remote peer. Then enable debugging features.
```
% pppd debug call peer-name
```
You might need to obtain debugging information from the peer in order to fix certain communications problems.
Check the resulting logs for communication problems. For more information, refer to General Communications Problems That Affect PPP.

General Communications Problems That Affect PPP

The following table describes symptoms that are related to log output from the procedure, How to Diagnose and Fix Communications Problems.

Table 21-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, the configuration might have broken flow control. The chat script might have failed. In this situation, see Table 21-5.
The `pppd debug` output shows that LCP starts, 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 to use `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 starts but terminates immediately.	IP addresses might be incorrectly configured.	Check the chat script to verify whether the script has incorrect IP addresses. If the chat script is correct, 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. Adjust the configuration if necessary.

How to Diagnose Problems With the PPP Configuration

Some PPP problems can be traced to problems in the PPP configuration files. The following procedure shows you how to isolate and fix general configuration problems.

Become superuser on the local machine or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Call the remote peer. Then enable debugging features.
```
% pppd debug call peer-name
```
Check the resulting log for the configuration problems. For more information, refer to Common PPP Configuration Problems.

Common PPP Configuration Problems

The following table describes symptoms that are related to log output from the procedure, How to Diagnose Problems With the PPP Configuration.

Table 21-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 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. The output also indictes that the link is dropped.

The peers' PPP compression configurations might be in conflict.

Disable CCP compression by adding the noccp option to /etc/ppp/options on one of the peers.

How to Diagnose Modem 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. However, you might have difficulties when determining 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. The following procedure helps determine whether a faulty modem configuration causes link problems.

Call the peer with debugging turned on, as explained in How to Turn on PPP Debugging.
Display the resulting /var/log/pppdebug log to check for faulty modem configuration.
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.

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, the modem configuration might have problems.

Troubleshooting

When you display the resulting /var/log/pppdebug log, the following symptoms in the output can indicate a faulty modem configuration. The local machine can hear the peer, but the peer cannot hear the local machine.

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 that are sent by the local machine.
The link terminates with a SIGHUP signal.

How to Obtain Debugging Information for Chat Scripts

Use the following procedure for obtaining debugging information from chat and suggestions for clearing common problems. For more information, refer to Common Chat Script Problems.

Become superuser on the dial-out machine or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Edit the /etc/ppp/peers/peer-name file for the peer to be called.
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"
```

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

The following is the main error that occurs 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

Common Chat Script Problems

Chat scripts are trouble-prone areas for dial-up links. The following table lists common chat script errors and gives suggestions for fixing the errors. For procedural information, refer to How to Obtain Debugging Information for Chat Scripts.

Table 21-5 Common Chat Script Problems

Symptom	Problem	Solution
`pppd debug` output contains `Connect script failed`	Your chat script supplies a user name and ssword. ogin: user-name ssword: password However, the peer that you intended to connect to does not prompt for this information.	Delete the login and password from the chat script. Try to call the peer again. If you still get the message, call the ISP. Ask the ISP for the correct login sequence.
The `/usr/bin/chat -v` log contains `"expect (login:)" alarm read timed out`	Your chat script supplies a user name and ssword. ogin: pppuser ssword: \q\U However, the peer that you intend to connect to does not prompt for this information.	Delete the login and password from the chat script. Try to call the peer again. If you still get the message, call the ISP. Ask the ISP for the correct login sequence.
`pppd debug` output contains `possibly looped-back`	The local machine or its peer is hanging at the command line and not running PPP. An incorrectly configured login name and password are in the chat script.	Delete the login and password from the chat script. Try to call the peer again. If you still get the message, call the ISP. Ask for the correct login sequence.
`pppd debug` output shows that LCP activates, but the link terminates soon afterward.	The password in the chat script might be incorrect.	Ensure that you have the correct password for the local machine. Check the password in the chat script. Fix the password if incorrect. Try to call the peer again. If you still get the message, call the ISP. Ask the ISP for the correct login sequence.
Text from the peer begins with a tilde (~).	Your chat script supplies a user name and ssword. ogin: pppuser ssword: \q\U However, the peer that you intend to connect to does not prompt for this information.	Delete the login and password from the chat script. Try to call the peer again. If you still get the message, call the ISP. Request the correct login sequence.
The modem hangs.	Your chat script contains the following line to force the local machine to wait for the `CONNECT` message from the peer: CONNECT ”	Use the following line when you want the chat script to wait for CONNECT from the peer: CONNECT \c End the chat script with `~ \c`.
`pppd debug` output contains `LCP: timeout sending Config-Requests`	Your chat script contains the following line to force the local machine to wait for the `CONNECT` message from the peer: CONNECT ”	Use the following line when you want the chat script to wait for CONNECT from the peer: CONNECT \c End the chat script with `~ \c`.
`pppd debug` output contains `Serial link is not 8-bit clean`	Your chat script contains the following line to force the local machine to wait for the `CONNECT` message from the peer: CONNECT ”	Use the following line when you want the chat script to wait for CONNECT from the peer: CONNECT \c End the chat script with `~ \c`.
`pppd debug` output contains `Loopback detected`	Your chat script contains the following line to force the local machine to wait for the `CONNECT` message from the peer: CONNECT ”	Use the following line when you want the chat script to wait for CONNECT from the peer: CONNECT \c End the chat script with `~ \c`.
`pppd debug` output contains `SIGHUP`	Your chat script contains the following line to force the local machine to wait for the `CONNECT` message from the peer: CONNECT ”	Use the following line when you want the chat script to wait for CONNECT from the peer: CONNECT \c End the chat script with `~ \c`.

How to Diagnose and Fix Serial-Line Speed Problems

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

The following behaviors cause 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.

pppd changes the speed that was originally set for the line to the speed that was set by /bin/login or mgetty. As a result, the line fails.

Log in to the dial-in server. Call the peer with debugging enabled.
If you need instructions, see How to Turn on PPP Debugging.
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.
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.
Check if a user started PPP from the mgetty command and accidentally specified a bit rate.
This action also causes serial-line speeds to conflict.
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 configuration.

How to Obtain Diagnostic Information for PPPoE

You can use PPP and standard UNIX utilities to identify problems with PPPoE. When you suspect that PPPoE is the cause of problems on a link, use the following diagnostic tools to obtain troubleshooting information.

Become superuser on the machine that runs the PPPoE tunnel, either PPPoE client or PPPoE access server.
Turn on debugging, as explained in the procedure How to Turn on PPP Debugging.

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.

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 with this procedure.

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.

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 with this procedure.

Run snoop. Then save the trace to a file.
For information about snoop, refer to the snoop(1M) man page.
```
# snoop -o pppoe-trace-file
```

View the snoop trace file.

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

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