Installing and Administering PPP

Chapter 6 141
Troubleshooting pppd
Scenario: With the debugging verbosity level set to 2 or more, messages appear in
the log file like ‘Bad FCS received,’ ‘Bad protocol (even), flushing frame,’
‘Short frame received (3 bytes),’ ‘Frame too long, flushing frame,’ ‘Missed
ALLSTATIONS, flushing frame,’ or ‘Missed UI, flushing frame.’
Solution: Some of the incoming messages are getting damaged in transit. If your
throughput is erratic or lower than you expect, then refer to the section
on "PPP connects and everything works, but it is slow and erratic."
If you see ‘Missed ALLSTATIONS’ while the link is coming up, after
‘Chat script succeeded’ but before the first ‘Received LCP
configure-Request,’ do not worry. The calling daemon is scanning the
characters it sees coming from the answering system, looking for the
start of a PPP frame that signifies the beginning of option negotiations.
While the contents of the answering machine’s /etc/motd scrolls by, it is
likely that the calling daemon will flush several of what it had thought to
be frames, but that turned out to be more text.
If the messages happen while the link is active, but only rarely, then do
not worry about them. The errors may be due to intermittent line noise
in the phone lines, or your computer may occasionally lose incoming
characters. This last possibility is likely if the errors tend to occur when
receiving large amounts of data.
Scenario: /etc/resolv.conf points at a name server out on the Internet someplace,
across the PPP link. When /etc/resolv.conf is in place and the PPP
connection is up, connectivity between internal hosts is fine. When
/etc/resolv.conf is in place and the PPP connection is down, connectivity
between internal hosts slows down significantly. Once the /etc/resolv.conf
is removed, connectivity returns to normal.
Solution: Local applications are trying to reverse-resolve incoming connection
addresses (even on the local network) into names, whether for
authentication (for example, /.rhosts and /etc/hosts.equiv) or just normal
operations (for example, telnetd making entries into /etc/utmp and
/var/adm/wtmp). When the DNS resolve routines cannot reach the name
server, they do not return a value that means "I don’t know" until some
timeout interval has passed. This is probably happening on every
connection attempt.