Subject: Re: Is anyone seeing lots of TCP checksum errors?
To: John F. Woods <email@example.com>
From: Mike Pumford <firstname.lastname@example.org>
Date: 11/08/1997 23:21:42
On Sat, 8 Nov 1997, John F. Woods wrote:
> I was a little too quick with the analysis; same conclusion, slightly
> different details.
> Five packets in a row were received on the ftp data channel with bad
> checksums; each of these had the correct checksum for the next packet.
> The fifth expected TCP packet was not received! (There is one PPP input
> error according to netstat, but that probably happened a couple of minutes
> ago, not while I was doing the test). In its place in the log there is
> a message from the ftp server on the ftp control channel ("220 Transfer
> complete", arriving 83221 bytes into a 138K transfer). After that are
> 6 more data packets with *correct* checksums (the last two checksums are,
> by "coincidence", equal to the checksums of the most recent two acknowledges.
> (Considering the predictability of TCP packets and the lack of sensitivity
> to positional exchange of the TCP checksum, it's not quite just a coincidence.)
You could be right. This is identical to the problems I have when VJ
compression is enabled. Interestingly I have recently come across reports
of this occuring on other completely different OS's when connecting to my
ISP. Either the network stack on these platforms is BSD derived and
inherits the same bug or the modem racks used by some ISP's contain broken
VJ compression code.
> I am receiving 1460 byte segments. tcpdump says I'm receiving 1504 byte PPP
> packets. I have PPP configured for 576 byte mru and mtu. HUH? (I guess
> they must have MRU negotiation turned off.)
NetBSD pppd used to ignore the negotiated MRU and always assume 1500 byte
packets could be sent. This is a fairly valid assumption since all PPP
implementations are required to deal with packets of this size during the
negotiation stages. I'm not sure if this is still the case but any code
based on this version will do the same thing.
> Anyway, it's still a router bug, it's just not the router bug I thought it
Certainly sounds like it. What sort of modem racks does your ISP use?
Mine uses Ascend racks.