On 8/2/06, Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> How do you know the data were not corrupted after the TCP checksum was
> performed?

ie in memory. I don't know. There's no real way to know where this happened.

To answer some other questions others have had, here's some details:

It's not a NetBSD thing. I'm only asking about this because I've never
personally seen this problem before and I'm worried about my own data
at home residing on NetBSD, which is a lot (digital home movies, etc).
I send it over a TCP/IP network, which I've always assumed is safe.

The corruption (happening in a non NetBSD environment, granted, but it
seems to be TCP/IP related) happens about 20% of the time, only on
this particular operation (backing up a very large database). There
are no problems (or no known ones I should say) in the application
when it's doing other things.

The network is not Ethernet based, and I'm not 100% sure what it is,
nor should I really need to know since I work for the application
which is layers away.

I made the assumption that it's the network, but in reality it could
be anywhere between where the application is generating it's own
checksums, or even the application itself, I suppose. Common sense
says it's either the network, or the TCP/IP implementations of the
operating systems involved.

So I guess what were saying is, if netstat is showing a lot of
checksum failures, which I'd expect to see once in a while, how many
are actually making it through to the application layer? Apparently,
it happens. I have what appears to be proof of this.

Scary.

Andy