Chapter 10 Troubleshooting PPP
This chapter is organized as a series of checks to make after you have configured PPP on your network. Thereafter, whenever you have trouble communicating over the PPP link, you can use PPP diagnostics to help troubleshoot problems.
In summary, you should do these checks in the following order:
-
Hardware
-
Interface status
-
Connectivity
-
Network interface activity
-
Local routing tables
-
Permissions
-
Packet flow
If PPP passes all the tests, you should be able to use TCP and UDP services such as rlogin, telnet, and ftp over the link. If the link still fails, turn on PPP diagnostics for assistance in troubleshooting.
The next sections describe these checks in detail.
Checking Hardware
Make sure that all modem and power cables are tightly seated. If you are having problems with PPP, always check the modems, cables, serial card, and phone lines first.
Checking Interface Status
After PPP is started, you can use ifconfig to monitor the current state of the line, using only the PPP interface name as an argument. Example 10-1 shows sample output from ifconfig for PPP links that are running.
Example 10-1 ifconfig Output for Point-to-Point Link
nomadb# ifconfig ipdptp0
ipdptp0: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500
inet 129.144.111.26 --> 129.144.116.157 netmask ffff0000
ether 0:0:0:0:0:0
|
You receive output similar to that in Example 10-1 for both standard and dynamic point-to-point links.
Example 10-2 ifconfig Output for Multipoint Link
nubian# ifconfig ipd0
ipd0: flags=c1<UP,RUNNING,NOARP> mtu 1500
inet 129.144.201.191 netmask ffffff00
ether 0:0:0:0:0:0
|
If ifconfig does not display UP and RUNNING, you did not configure PPP correctly. For more information on ifconfig, see "ifconfig Command" and the ifconfig(1M) man page.
Checking Connectivity
Use the ping command to verify that the connection is up or can be established. For example, consider the following simple round-trip test:
# ping elvis |
where elvis is the name of the PPP interface on the remote host. If the resulting display is
elvis is alive |
then packets can be sent to and received from elvis. If not, a routing problem exists at some point between the local and remote hosts. For more information on ping, refer to "ping Command" and the ping(1M) man page.
Checking Interface Activity
Use the netstat command as follow, to check that packets are being sent and received correctly:
# netstat -i |
Refer to "netstat Command" and the netstat(1M) man page.
Checking the Local Routing Tables
Use the netstat command to display the local routing tables:
# netstat -r |
The following is sample output:
Routing tables Destination Gateway Flags Refcnt Use Interface sahara deserted UGH 0 0 ie1 karakum labia UGH 0 0 ie1 frodo bilbo UGH 1 12897 ipdptp0 route7 route7 UGH 0 0 ie0 eastgate route71 UGH 0 158 ie0 backbone pitstopbb U 1 16087 ie1 dresdenpc route1 UG 0 0 ie1 loopback localhost U 2 113436 lo0 swan-bb pitstop U 406 146044 ie0 dallas2 route7 UG 0 0 ie0 trainingpc route62 UG 0 0 ie1 |
Make sure there is a routing table entry for each possible destination network. In particular, PPP devices, listed under Interface, should be matched with the appropriate host names listed under Gateway. The Gateway entry should, in turn, be matched with the correct entry under Destination.
Otherwise, if you are using static routing, add the appropriate static routes. If you are using dynamic routing with in.routed:
-
Verify that in.routed is running by typing:
# ps -e | grep route
If the routing tables still don't look correct, become superuser and continue with the next steps.
-
Kill in.routed by typing the process ID you got from ps -e as the argument to kill. For example, if 1384 was the process ID, you would type:
# kill 1384
-
Flush the routing tables as follows:
# /usr/sbin/route -f
-
# /usr/sbin/in.routed
Checking Permissions
If you attempt to use rsh and receive the message Permission denied, the remote system's /etc/hosts.equiv or /.rhosts file does not contain the sending system's host name or does not contain the line +.
Checking Packet Flow
Check the packet flow next. Use the snoop command to observe packets from the network and observe their contents. Example 10-3 shows some sample output from snoop.
Example 10-3 Sample Output from snoop
# snoop -d ipdptp0
Using device ipdptp0 (promiscuous mode)
corey -> pacifica7 RLOGIN C port=1019
hugo -> ponc3 RPC R XID=22456455 Success
ponc3 -> hugo NFS C WRITE FH=1B29 at 32768
commlab3 -> commlab4 TELNET R port=34148
commlab4 -> commlab3 IP D=129.144.88.3 S=129.144.88.4 LEN=46, ID=41925
commlab3 -> commlab4 TELNET R port=34148
commlab4 -> commlab3 ICMP Echo request
commlab3 -> commlab4 ICMP Echo reply
commlab4 -> commlab3 FTP C port=34149
commlab4 -> commlab3 FTP C port=34149
commlab3 -> commlab4 FTP R port=34149
commlab4 -> commlab3 FTP C port=34149
|
The ipdptp0 device name mentioned in the first line of the output Using device ipdptp0 indicates a point-to-point connection.
Note -
You need to have the link up and some traffic generated in order to use snoop to check the line status.
snoop captures packets from the network and displays their contents. It uses both the network packet filter and streams buffer modules to provide efficient capture of packets from the network. Captured packets can be displayed as they are received or saved to a file for later viewing.
snoop can display packets in a single-line summary form or in verbose multiline forms. In summary form, only the data pertaining to the highest-level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.
For more information about the snoop command, refer to the snoop(1M) man page.
Using PPP Diagnostics for Troubleshooting
If you have problems with a link after successfully establishing modem connections, you can use PPP-level diagnostics for troubleshooting. PPP-level diagnostics report detailed information about the activities of a link to help you determine where it is failing.
To obtain diagnostic information, add the line debug_level 8 to the path section of the asppp.cf file. (If you are very knowledgeable about data communications, you might want to use debug level 9, which provides very detailed information.) Here is a sample configuration file that invokes PPP diagnostics.
ifconfig ipdptp0 plumb nomada nubian-ppp up path interface ipdptp0 peer_system_name nubian-ppp #The name in the /etc/uucp/Systems file inactivity_timeout 300 #Allow five minutes before timing out debug_level 8 #Start up PPP diagnostics for this link |
For complete details about the aspppd.conf file, refer to "Editing the /etc/asppp.cf Configuration File".
How to Set Diagnostics for Your Machine
Set diagnostics on the host you want to monitor as follows:
-
Become superuser and change to the /etc directory.
-
Edit the current asppp.cf file and add the following to the path section: debug_level 8.
-
Save the file, making sure the permissions are set to 600.
-
Kill the current aspppd daemon and restart it.
#kill PID #aspppd
where PID is the process ID for aspppd.
PPP reports diagnostic information in /var/adm/log/asppp.log.
Analyzing Diagnostic Output
When a PPP link runs correctly, the asppp.log file includes diagnostic information in addition to its normal output. This section explains what the diagnostic messages mean. If your output is different, refer to RFC 1331.
Host and Modem Setup
This section contains messages that occur as the local host sends configuration information to the modem, and then as the modem tries to dial the remote host. These initial activities are actually handled by the UUCP daemon. You might think of them as the UUCP portion of asynchronous PPP communications. (Refer to Chapter 12, UUCP Databases and Programs, for complete details on UUCP.)
The two messages below should always appear at the beginning of the session. They indicate that the aspppd daemon has started successfully.
11:53:33 Link manager (1057) started 04/14/94 11:53:33 parse_config_file: Successful configuration |
The next line indicates that a packet was routed to the ipdptp0 interface on the local host. It helps you to determine if a dial-out is occurring correctly. For example, if you tried to ping the remote machine and this message isn't in asppp.log, the packet was lost, probably due to a routing problem.
Next, UUCP looks for an entry that matches Ppac7 in a chat script in the /etc/uucp/Systems file. It then reports that it found an entry that had a device type ACUTEC. (For more information on the Systems file, refer to "/etc/uucp/Systems File".)
11:53:46 process_ipd_msg: ipdptp0 needs connection conn(Ppac7) Trying entry from '/etc/uucp/Systems' - device type ACUTEC. |
UUCP then finds the dialing information for an ACUTEC dialer in the /etc/uucp/Devices file. When it finds the information, it opens the appropriate serial port on the local host and sets it with a speed of 9600. (For more information on /etc/uucp/Devices, see "/etc/uucp/Devices File".)
Device Type ACUTEC wanted Trying device entry 'cua/a' from '/etc/uucp/Devices'. processdev: calling setdevcfg(ppp, ACUTEC) fd_mklock: ok fixline(8, 9600) gdial(tb9600-ec) calle |
UUCP looks for the entry tb9600 in the /etc/uucp/Dialers file and then sends out these messages.
Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers'
expect: ("")
|
The host waits a couple of seconds and then sets the registers on the modem. The information shown in the log below is modem-specific. It comes from the /etc/uucp/Dialers file.
got it sendthem (DELAY) APAUSE APAUSE APAUSE T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>) |
The next lines are the dialog between the modem and the host machine. expect (OK^M) means that the host expects the modem to send an "okay." The words got it at the end of the second line indicate that the host got the "okay" message from the modem.
expect: (OK^M) AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it |
Next, the host sends the string below to the modem, which does the actual dialing. The phone number in the second line is retrieved from the entry for the remote host in the /etc/uucp/Systems file.
sendthem (ECHO CHECK ON A^JATTDDTT99003300887744^M^M<NO CR>) |
The line beginning with expect indicates that the local host expects to get a response from the modem at a speed of 9600 bps. The next line indicates that the modem responded.
expect: (CONNECT 9600) ^M^JCONNECT 9600got it |
This line indicates that hardware flow control has started on the link. The host obtains flow control information from the /etc/uucp/Dialers file.
STTY crtscts |
In the next series of messages, the local host waits for the remote host to send it a standard UNIX login prompt.
getty ret 8
expect: ("")
got it
sandiest (^J^M)
expect: (login:)
|
The next messages indicate that the local host has received the login prompt from the remote. It then retrieves the appropriate login sequence from the chat script in the /etc/uucp/Systems entry for the remote host. This sequence is Ppong^M, which is required for login by the remote host.
^M^J^M^Jlogin:got it sendthem (Ppong^M) |
In these messages, the local host waits for the ssword prompt from the remote host. Upon receipt of the prompt, the local host sends the password retrieved from the chat script in the /etc/uucp/Systems entry for the remote host.
expect: (ssword:) login: Ppong^M^JPassword:got it |
The following messages indicate that dialing and modem connection completed successfully.
sendthem (ppptest1^M) call cleanup(0)^M |
Communications Between the Local and Remote Hosts
At this point, PPP communications start, as the link between local and remote hosts is now established.
The first lines in this part of the session constitute a configuration request (Config-Req). This is the first PPP packet sent to the remote host. The configuration request is one example of a Link Control Protocol (LCP) packet. It requests that configuration be set up and then sets up the PPP link between endpoint machines. Example 10-4 shows a sample configuration request.
Example 10-4 Configuration Request
11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
Here is a description of the configuration request shown in Example 10-4.
-
11:54:20 - Time stamp field, indicating the time when the packet was sent
-
004298 - Number of the packet
-
ipdptp0 - Network interface used
-
SEND PPP ASYNC - Indicates that the modem is sending asynchronous PPP
-
29 Octets - Amount of data the host sent
-
LCP - Packet type to send
-
ID=4c - Identifier associated with the packet; it is actually part of the packet
-
LEN=24 - Length of the LCP part of the packet
The remaining items are a list of options to be negotiated between hosts.
-
MRU=1500 - Maximum Receive Unit (MRU), the largest packet size the calling host can receive from the remote host
-
ACCM=00000000 - Asynchronous Character Map (ACCM), the mask sent to the remote host that tells what control characters to escape on transmission
-
MAG#=69f4f5b2 - Magic number field; used for loopback detection mechanism
-
ProtFCOMP AddrCCOMP - Asks for the remote host to compress certain parts of the frame header (protocol field, address field).
The next lines are reporting invalid PPP packets. They come from the remote host, which is sending out UNIX text. This does not indicate a problem with PPP.
11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7
Octets [BAD FCS] {Unrecognized protocol: 1}
11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS]
{Unrecognized protocol: 880a}
|
In these packets, the local host receives the remote host's request for configuration, then sends out another configuration request. The packets are identical except for their ID fields. The ID field helps to distinguish between the two packets.
11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
In this packet, the local host acknowledges the remote request by sending it a configuration acknowledgment (Config-ACK).
11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
The local host receives a configuration request (Config-Req) from the remote host.
11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
In these packets, the local host acknowledges the second packet sent by the remote host and receives the remote host's acknowledgment.
11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- ACK ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
Here the local host negotiates parameters about IP transmission. LEN=16 gives the packet size. VJCOMP indicates Van Jacobsen header compression. IPADDR is followed by the calling host's IP address.
11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- Req ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
This packet indicates that the local host has received IP configuration from the remote host, including its IP address.
11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-Req ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 |
The local host sends this ACK to the remote host and receives an ACK from the remote host.
11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- ACK ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-ACK ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
The first message below indicates that IP has started on the link. The next message indicates that the local host is sending IP traffic over the link.
11:54:22 start_ip: IP up on interface ipdptp0, timeout set for 120 seconds 11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO |
In the first message below the local host receives IP traffic from the remote host. The subsequent messages indicate that the interface was disconnected because of an idle time-out.
11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO 11:56:25 process_ipd_msg: interface ipdptp0 has disconnected 11:56:25 disconnect: disconnected connection from ipdptp0 |
The next messages begin the termination sequence. The first message indicates that the remote host has sent a packet to terminate the IP layer. The second is the local host's acknowledgment of the request to terminate.
11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term- REQ ID=38 LEN=4 11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK ID=38 LEN=4 |
The local host receives a request to terminate the LCP layer. The second message is an acknowledgment of the request, causing a graceful shutdown.
11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ ID=39 LEN=4 11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK ID=39 LEN=4 |
This message indicates that the link has closed.
11:56:29 004317 ipdptp0 PPP DIAG CLOSE |
- © 2010, Oracle Corporation and/or its affiliates