This chapter contains information for troubleshooting common problems that occur with Solaris PPP 4.0. The following topics are covered:Tools for Troubleshooting PPP Solving PPP-Related and PPPoE-Related Problems Fixing Leased-Line Problems Diagnosing and Fixing Authentication 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. Use the following task map to quickly access advice and solutions for common PPP problems.Task Definition For Instructions Obtain diagnostic information about the PPP link Use PPP diagnostic tools to obtain output for troubleshooting. How to Obtain Diagnostic Information From pppd Obtain debugging information for the PPP link Use the pppd debug command to generate output for troubleshooting. How to Turn on PPP Debugging Troubleshoot general problems with the network layer Identify and fix PPP problems that are network-related by using a series of checks. How to Diagnose Network Problems Troubleshoot general communications problems Identify and fix communications problems that affect the PPP link. How to Diagnose and Fix Communications Problems Troubleshoot configuration problems Identify and fix problems in the PPP configuration files. How to Diagnose Problems With the PPP Configuration Troubleshoot modem-related problems Identify and fix modem problems. How to Diagnose Modem Problems Troubleshoot chat script-related problems Identify and fix chat script problems on a dial-out machine. How to Obtain Debugging Information for Chat Scripts Troubleshoot serial-line speed problems Identify and fix line–speed problems on a dial-in server. How to Diagnose and Fix Serial-Line Speed Problems Troubleshoot common problems for leased lines Identify and fix performance problems on a leased line. Fixing Leased-Line Problems Troubleshoot problems related to authentication Identify and fix problems related to the authentication databases. Diagnosing and Fixing Authentication Problems Troubleshoot problem areas for PPPoE Use PPP diagnostic tools to obtain output for identifying and fixing PPPoE problems. How to Obtain Diagnostic Information for PPPoE PPP links generally have three major areas of failure:Failure of the link to be established Poor performance of the link during regular usage Problems that can be traced to the networks on either side of the link The easiest way to find out if PPP works is to run a command over the link. Run a command such as ping or traceroute to a host on the peer's network. Then observe the results. However, you should use PPP and UNIX debugging tools to monitor performance of an established link or to troubleshoot a problematic 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.The next procedure shows how to view the current operation of a link on the local machine. 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. Run pppd with the serial device configured for PPP as the argument:# pppd cua/b debug updetachThe 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 that is produced is sent to the /etc/ppp/connect-errors file. # 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., Oct 6 2004 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 6 2004 09:36:22) rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>] sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Sep 15 2004 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., Sep 15 2004 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., Oct 6 2004 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 6 2004 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 # pppd /dev/se_hdlc1 default-asyncmap debug updetach pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2004 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 2004 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 2004 14:31:44)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2004 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 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. &rolestepA;Create a log file to hold output from pppd.# touch /var/log/pppdebug Add the following syslog facilities for pppd in /etc/syslog.conf.daemon.debug;local2.debug /var/log/pppdebug Restart syslogd.# pkill -HUP -x syslogd 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. View the contents of the log file.# tail -f /var/log/pppdebugFor an example of a log file, see Step 3. 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 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-asyncmapThese 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. If the machine is a router, check the optional features.# ndd -set /dev/ip ip_forwarding 1For more information about ndd, refer to the ndd1M man page.In the Solaris 10 release, you can use routeadm1M, instead of ndd(1M).# routeadm -e ipv4-forwarding -uThe 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 netstat1M 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. 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.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 traceroute1M 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. 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-nameYou 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. The following table describes symptoms that are related to log output from the procedure, How to Diagnose and Fix Communications Problems.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. 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. The following table describes symptoms that are related to log output from the procedure, How to Diagnose Problems With the PPP Configuration.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. 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 ping1M 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 0If interface errors increase over time, the modem configuration might have problems. 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. 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] FailedThe example shows timeout while waiting for a (CONNECT)string. When chat fails, you get the following message from pppd:Connect script failed 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.Symptom Problem Solution pppd debug output contains Connect script failed Your chat script supplies a user name and ssword.ogin: user-name ssword: passwordHowever, 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\UHowever, 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\UHowever, 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 \cEnd 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 \cEnd 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 \cEnd 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 \cEnd 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 \cEnd the chat script with ~ \c. 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 requestsThis 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. 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: connectedIf 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 snoop1M man page.# snoop -o pppoe-trace-file View the snoop trace file.# snoop -i pppoe-trace-file -v pppoeETHER: ----- 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 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. Symptom Problem Solution The link does not start. CSU biopolar violations (CSU BPVs) can be the cause. One end of the link is set up for AMI lines. The other end is set up for ESF bit–8 zero substitute (B8Zs). If you are in the United States or Canada, you can directly fix this problem from the menu of the CSU/DSU. Check the CSU/DSU manufacturer's documentation for details. In other locales, the provider might be responsible for fixing CSU BPVs. The link has poor performance. The pppd debug output shows CRC errors when sustained traffic is on the link. Your line might have a clocking problem, caused by misconfigurations between the telephone company and your network. Contact the telephone company to ensure that “loop clocking” is in use.On some unstructured leased lines, you might have to supply clocking. North American users should use loop clocking. The following table describes solutions for general authentication problems.Symptom Problem Solution pppd debug output shows the message Peer is not authorized to use remote address address. You are using PAP authentication, and the IP address for the remote peer is not in the /etc/ppp/pap-secrets file. Add an asterisk (*) after the entry for the peer in the /etc/ppp/pap-secrets file. pppd debug output shows that LCP starts but terminates shortly afterward. The password might be incorrect in the database for the particular security protocol. Check the password for the peer in the /etc/ppp/pap-secrets or /etc/ppp/chap-secrets file.