C H A P T E R N I N E
Debugging Links
Approach
When PPP fails to function properly, a fair bit of detective work is sometimes
required to find the source of the problem. In general, the problems urs e fall
into three categories: communications, negotiation, and networking. Of cour,
only the negotiation is actually part of PPP, but it is necessary to isolate the prob-
lem to one part of the system in order to repair it.
Network-Layer Problems
Networking problems are usually the easiest to isolate. If the link comes up, but
no data pass, or only a few hosts are reachable, it is likely to be a networking
problem. A general rule of thumb for establishing that the problem is indeed
related to networking is to disable all optional protocols, such as compression,
and establish the link. If the problem still appears, networking is suspect.
Debugging of networking problems usually requires an intimate knowledge of
the routing and forwarding techniques ud. Some general hints are as follows.
•Check the address ud.The network-layer address ud must be prop-
erly assigned in order to communicate with other systems on the network.
They usually cannot be picked arbitrarily. For IP, 10.0.0.0/8, 172.16.0.0/12,
253
254D E B U G G I N G L I N K S and 192.168.0.0/16 are rerved address. They can be routed within an
organization, but they cannot be routed on the general Internet. If the
address are in u, a NAT or proxy rver must be installed to reach the
Internet.
•Check t he rout ing t ables.Examine the network-layer routing tables not
only on the machine exhibiting the problem but on the peer’s side as well,
and on any other routers on either side of the link that are in the path to the
destination system. It is very common for networking problems, especially
tho that result in only some hosts being reachable, to be due to misconfig-
uration of tho intermediate routers. Don’t forget to check both the path
to the destination and the path back; more often than not, the problem is in
可能英文
the return path.
•Check the optional features.Most systems do not forward network packets
by default, so this must be explicitly enabled if the system is ud as a
英语骂人的话
router. This is done with different commands on different systems:
ndd -t /dev/ip ip_forwarding 1Solaris
echo 1 > /proc/sys/net/ipv4/ip_forward Linux 2.0
echo 1 > /proc/sys/net/ipv4/conf/all/forward Linux 2.2+
sysctl -w net.inet.ip.forwarding=1FreeBSD
no -o ipforwarding=1AIX
nettune -s ip_forwarding 1HP/UX
Some systems, such as recent versions of Linux (kernel Version 2.2 and
above), do not proxy ARP by default, even if pppd is configured with the
“proxyarp” option. If proxy ARP is to be ud, it must also be enabled with
this command:
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
•Check the available statistics.Most network-layer implementations provide
veral counts, such as packets received and packets forwarded. If the peer
system is not too busy, it is often possible to check the statistics, attempt to
contact a host, then reexamine the statistics and find which ones changed. If
this does not reveal a problem, check the same statistics on the next router
or the destination host itlf.
For instance, if “netstat -s” shows an increasing number of “IP packets not forwardable” or “ICMP input destination unreachable,” it is likely that
N E G O T I AT I O N A N D C O M M U N I C AT I O N S255 this system is missing a needed route. If it shows an increasing number of
“ICMP time exceeded” errors (and the “traceroute” utility is not in u at
the time), the problem is likely to be a forwarding loop—two routers are t
to forward the same destination address to each other, and the packets
bounce back and forth until the TTL (time-to-live) expires. Finally, if it
shows an increasing number of “redirects nt” or “redirects received,” the
problem may be a misconfigured network mask on a broadcast interface.
(The names of the counters will vary depending on the system ud. For
instance, the Solaris names that correspond to the five counters discusd
在线反译above are “ipOutNoRoutes,” “icmpInDestUnreachs,” “icmpInTimeExcds,”
“icmpOutRedirects,” and “icmpInRedirects,” respectively.)
•Check the name rvice configuration.If the name rvice is misconfigured,
you may find that numeric network address work but symbolic names do
学位类别not, or that commands such as “netstat,” “ping,” “route,” “tcpdump,” and
“traceroute” hang unless the “-n” flag is given. On Unix-like systems, name
rvice is configured through /f. This file usually looks
分别英语like this:
namerver 192.168.1.1
On Windows machines, this will appear in the Control Panel -> Network
menu. The actual domain name and address will be different in your config-
uration. Contact your ISP to obtain the correct address.
Negotiation and Communications
The distinction between negotiation problems and communications problems
can be difficult to discern sometimes. Some are obvious, such as chat script fail-
ures. Some types of communications problems, however, such as bad ACCM
ttings, can look like negotiation problems. Listed below are some of the symp-
toms of communications errors.
•Very long delays between received messages.
On a PC Linux system, this is usually caud by the wrong IRQ level config-
ured for the rial port with the trial utility. The debug messages have
a characteristic 19- or 20-cond interval when this failure occurs.
256D E B U G G I N G L I N K S •Link terminates with “too many Configure-Requests” message.
This usually means that one system cannot hear the other. Possible caus
include bad cabling, incorrect bit rate ttings, broken flow control, and
chat script failure.
环球雅思报名On a PC Linux system, this can also be caud by improper trial configuration in /etc/rc.d/rc.rial, including tting “uart 16450”
when “uart 16550A” should be t. Improper configuration of the rial
driver caus the hardware receive FIFO to be disabled, which often leads
to overruns and corrupted rial data.
•Link terminates with “possibly looped-back” message.
有声读物打包下载This is most often caud when the peer is not actually running PPP, but is
rather left sitting at some kind of command-line prompt due to a chat script
error. This is not a PPP failure.
When dialing into ISPs, the chat script failure is usually due to the u of ur name and password scripting when this is either not required or not
allowed by the ISP. Some ISPs will say that you should “u PAP” instead—
this means that no scripting is required. The last line of the chat script for
the ISPs should be:
CONNECT'\d\c'
Another possible cau of this problem, although much rarer, is that PPP
authentication data are incorrectly configured and the peer has silently
stopped running PPP due to the misconfiguration.
•LCP comes up, but all protocols above that fail or exhibit unexpected CRC
errors.
This is usually caud by an incorrectly t ACCM. Try tting the ACCM
back to the standard default of FFFFFFFF, or to the Windows default of
000A0000.
•LCP comes up, but link terminates shortly afterward.
This can be caud by an incorrect password, depending on how the peer
implements the curity protocols. In MP systems, this can be caud by a
failure to match the expected Endpoint-Discriminator, MRRU, MRU, or
Short Sequence Number options.
•IPCP comes up and terminates immediately.
This is usually the result of IP address configuration errors, such as missing
or duplicate address. If no local errors are evident, check the debug logs
for the peer.
C O N F I G U R AT I O N P R O B L E M S257
•Very low performance.
This can be due to flow control configuration errors, modem t-up errors,
石家庄专接本and DTE rates configured either too low or above what the system is able
to handle. On Linux, this is sometimes cured with the “spd_vhi” option to
trial, which ts the data rate to the maximum of 115.2Kbps when
pppd requests 38.4Kbps.
The PPP debugging Web pages referenced in Chapter 11 can be a big help in
isolating the problems for particular implementations.
Configuration Problems
Listed below are some common problems in PPP configuration.
•IP-Address option is Configure-Rejected or fails.
This often occurs when no remote IP address is configured and the peer
refus to provide one. For PPP links pointing to the Internet as a default
route (the usual ca for a link to an ISP), the remote address is irrelevantitme
privilegedand can be supplied on the pppd command line like this:
0:192.168.1.1
•“Peer is not authorized to u remote address 1.2.3.4” log message.
This occurs when pppd is ud as a rver becau the remote address for
the dial-up ur is not listed in the pap-crets file. Adding an extra “*” at
the end of the associated entry will cure the problem.
•LCP “No network protocols running” right after IPCP Configure-Ack.
This occurs on Linux systems running a version of pppd that is incom-
patible with the kernel. PPP should be updated in this ca.
•Can communicate with everything except one network.
On Windows machines, this is caud by having the Ethernet interface con-
figured with a static IP address but not connected. This problem occurs
most often with laptop machines that are plugged into an Ethernet at work
and ud for dial-up on the road. The solution is either to disable the Ether-
net interface manually through the Control Panel when using PPP or to
switch to DHCP for address assignment on the Ethernet.
