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
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.
- Check the routing tables on both the local machine and the peer.
- 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.
- Run statistics on the local machine.
- Call the peer.
- 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:
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:
- Lock the DTE rate on the modem.
- Do not use autobaud.
- 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
