While this might be one cause, it is certainly not necessarily so.
And judging from the reponses you received on the list, people are
pretty confused about how VJ header compression works.
In a nutshell, VJ compression relies on the TCP checksums to maintain
synchronization in the presence of dropped packets. In practice, if
you get a bad PPP frame (for example, if your kernel or bus are too
swamped to keep up with the modem), it will be discarded at the PPP
level because of its bad PPP frame CRC. (And, yes, that's a CRC and
not a checksum.) But, unless you've enabled an appropriate "kdebug"
flag on the PPP daemon, you won't get a kernel message at all; you
have to check the "RX errors" in the output of "ifconfig ppp0" to see
these errors occurring.
However, this dropped packet means the compression stream is now out
of synch. Therefore, the next packet, if it arrives undamaged, will
pass the PPP CRC test and, typically, fail the TCP checksum test
because the loss of synchronization leads to an incorrect regeneration
of the TCP header. The sending PPP daemon notices that packets are
being resent, assumes loss of synchronization has occurred, and sends
an uncompressed packet to resynchronize. This is how it's *supposed*
to work. Those interested in the details should consult RFC 1144,
section 4, "Error Handling".
Yes, disabling VJ compression will make the messages go away, but you
haven't made the *problem* go away. You are still, presumably,
dropping PPP frames for some reason, and the packets they contain must
be resent. You'll just be slaughtering your interactive connection
performance for no reason.
The right thing to do is to find out *why* you are dropping PPP
frames. If you've got a cheap modem without a 16550 UART or if you've
got a flakey bus, you might just have to live with the problem until
you can replace the hardware. Try reducing the baud rate in the
meantime; you'll have to do some benchmarking to determine the best
tradeoff between "being slow" and "being accurate". If you discover
you're inadvertently sharing interrupts with your serial mouse (so
*that's* why moving my mouse causes checksum errors!), you can take
some remedial action.
Or, the cause may be more obscure. I recently installed a new, fast
IDE hard drive on a very slow, obsolete 486/33 with an el-cheapo
motherboard. I immediately received an absolute avalanche of checksum
messages which could be reduced, but not eliminated, using a lower
baud rate out to the modem. It turned out that data transfers with
the new, fast drive were causing interrupts to be masked for way too
long. In this case, a "hdparm -u 1" on the device fixed the problem,
and I don't think I've had a checksum error since.
Good luck!
Kevin <buhr@stat.wisc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu