Re: Massive TCPv4 bad checksum
Andi Kleen (ak@muc.de)
Tue, 20 Oct 1998 12:20:47 +0200
On Tue, Oct 20, 1998 at 11:18:12AM +0200, Geert Uytterhoeven wrote:
> On Mon, 19 Oct 1998, Andi Kleen wrote:
> > On Sun, Oct 18, 1998 at 10:12:41PM +0200, Geert Uytterhoeven wrote:
> > > On Sun, 18 Oct 1998, H.J. Lu wrote:
> > > > > Geert Uytterhoeven <geert@geert.cs.kuleuven.ac.be> writes:
> > > > > > On Sat, 17 Oct 1998, H.J. Lu wrote:
> > > > > >> I have massive TCPv4 bad checksum on my CSLIP link from
> > > > > >> my CSLIP server to my machine ever since I upgraded to
> > > > > >> linux 2.1.1xx. Any suggestions?
> > > > >
> > > > > > My m68k box generates plenty of these messages when receiving packets from my
> > > > > > PPC box. This would indicate a bug in the checksum code for either (or both)
> > > > > > m68k and PPC.
> > > > >
> > > > > > But I also see the message on my AXP box, when receiving packets from the PPC.
> > > > > > The Intel box on our network reports no bad checksums at all. None of the
> > > > > > Linux boxes report any bad checksums from the Winslows machines.
> > > > >
> > > > > > Who's (who are?) the bad guy(s)?
> > > > >
> > > > > Is there a systematic on what types of packets arrive with bad checksums?
> > > > >
> > > >
> > > > Most of the bad packets are from ftp and rsh. As the result, my
> > > > ftp and CVS over rsh on my CSLIP link are much slower than 2.0.
> > >
> > > Mine come mostly from ssh, and some from auth:
> >
> > Is it possible that these were RST packets (caused when the connection
> > is closed on the other side) ?
>
> How can I find out?
Try if telnet otherhost notboundport causes a checksum error. If not I
can supply a tcpdump patch to check tcp checksums.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/