[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070918124446.89100042.billfink@mindspring.com>
Date: Tue, 18 Sep 2007 12:44:46 -0400
From: Bill Fink <billfink@...dspring.com>
To: Florian Weimer <fweimer@....de>
Cc: Urs Thuermann <urs@...ogud.escape.de>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"L F" <lfabio.linux@...il.com>,
"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
"James Chapman" <jchapman@...alix.com>, <netdev@...r.kernel.org>
Subject: Re: e1000 driver and samba
On Tue, 18 Sep 2007, Florian Weimer wrote:
> * Urs Thuermann:
>
> > How can a corrupted frame pass the TCP checksum check?
>
> The TCP/IP checksums are extremely weak. If the corruption is due to
> defective SRAM or something like that, it's likely that it causes an
> error pattern which is 16-bit-aligned. And an even number of
> 16-bit-aligned bit flips is not detected by the TCP checksum. 8-(
>
> Actually, nobody should use TCP without application-level checksums
> for that reason. But of course, there is HTTP.
But in this specific case, IIRC there were _no_ receive checksum
errors seen, and it would seem odd that any bit corruption was
_always_ an even number of 16-bit-aligned bit flips.
Also, I don't know anything at all about the SAMBA fs/protocol, but
I would expect it would have some kind of stronger data integrity
capability that should catch such errors. Which would be another
reason implying the data corruption problem is above the network
layer, and perhaps a hardware error of some kind on the write path
to the disk (also could possibly be a software bug of some kind
in that path).
-Bill
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists