> Jul 26 23:34:07 localhost kernel: ppp: frame with bad fcs, excess = faab
> I haven't found out what this means yet. Is this the ultimate source of the
> problem, so that no number of retried config-requests will ever succeed? I
> get a few hits when searching for "frame with bad fcs" on Alta Vista, but
> nothing useful yet. [Some of the referenced pages are not coming up right now
> because the servers are overloaded. Also, if you speak Portuguese(?) or
> Dutch(?), you may be able to help us by doing the Alta Vista search and
> translating some of the archived mail messages in those languages.]
> Since this message is getting kind of long, I'll pinch it off here and
> followup with another post in the same thread on the "bad fcs" problem.
> Meanwhile, perhaps some of the others of you who are getting the "timeout
> sending Config-Requests" could start pppd with the "debug" and "kdebug 1"
> options and try to trap a timeout, just to see whether we're all getting the
> same "bad fcs" error, or whether we're getting different errors that happen to
> have the same gross result.
Ah, where was I. Oh, yes: At
Vista turns up a July'97 post by a certain Rob Riggs, which includes this juicy
"The symptom for FIFO overflows and flip buffer overflows on a PPP connection is
the same: dropped frames. If kdebug is set in pppd, they both cause the kernel to
report the same error, "ppp: frame with bad fcs". Unless you modify the kernel to
report on both conditions, you cannot tell which problem is culprit."
Just the facts, Ma'am. It doesn't tell me a thing, but I report it on the chance
it will tip someone else off to the problem.
Another hit provides a couple of links to relevant archived messages. I like
this one, from Brian Candler back in Jan'96
"fcs = Frame Check Sequence, a checksum which PPP puts on the end of each
datagram. If you get errors only for certain users, the most likely cause is that
they have not got hardware handshaking (CTS/RTS) set up properly.
"You should check their modem configuration - USR Sportsters are a common problem
since their factory defaults (AT&F) are for software handshaking (XON/OFF).
Choose the defaults setting for hardware handshaking (look in the manual - AT&F1
or AT&F2 ?) then do AT&W to store the settings.
"It might also be their client software settings. How you do this depends on the
software. For example, Trumpet Winsock needs 'Hardware Handshake' checked in the
Setup screen; a Linux box needs 'crtscts' on the pppd command line."
This is what I was told to do once in the past, long before anyone mentioned
fcs. It hasn't helped, but I used &F1 and he seems to be undecided between that
and &F2, so maybe I need to look that up and give it a try. I do have a
USRobotics modem, and I remember that at least one other recent poster did as
well, so if that's what you have you may want to give this a try. (Let me know
if you try it and it works, because I'll be posting a summary if we ever get to
the bottom of this.)
And here's a surprise from my very own department's Web server, a page dated
excerpted for brevity):
"On my machine ... I have been experiencing a lot of trouble trying to setup a
reliable PPP connection over a V34 (28.8kb/s) modem. Symptoms were a lot of
"frame with bad fcs" and "frame tossed, reason = 4" messages on the console, and
poor overall throughput. Such problems can of course have many causes including
wrongly configured modems, bad cables, wrongly configured flow control and many
more. After eliminating all those potential reasons, I got help from the Usenet
"Theodore pointed out that ``some other device driver (the IDE disk driver is a
really bad this way) keeps interrupts off too long, and by the time the serial
driver can get control, it's too late. If you can correlate the input overrun
messages to disk activity, then you should take a look at man page for the
"hdparm" program. In particular, take a look the "-u" option, which is documented
for solving the input overrun message, but which causes SEVERE DISK CORRUPTION
for some IDE interfaces. Read the man page, including the part of backing up your
hard disk first, and decide for yourself if you're willing to risk it.''
"I followed their advice by installing the hdparm-2.3 program, BACKING UP MY
WHOLE DISK and trying (as root) "hdparm -q -u 1 /dev/hda". It did make all the
PPP errors disappear. ... It has worked flawlessly since then, and I now enjoy
ftp transfers at 3+ kb/s."
This sounds like a last resort kind of thing for me.
That about does it for the Alta Vista hits that I can get to and read. I
remembered that AV does crude translations, and looked at the Portuguese that
way, but no joy there. There are still some hits in Dutch and (apparently) a
Slavic language that AV won't even try to translate.
The second item above looks most promising, so I'll study up on the &F2 and
report back on it later. Meanwhile, I'd be most happy to hear from anyone else
that is working on the same problem.