> The corruptions which I saw in the trace all appeared to be the result
> of insertion of an extra 16 bits of zeros.  The header checksum is
> only over the header (duh), so if the corruption occurred later in the
> packet it wouldn't be picked up.

He was seeing some packets rejected for "unknown version number", which is
part of the header.  However, I now see that the version number is checked
before the checksum (duh.  A new version might have a new checksum algorithm.),
so I was mistaken in believing that there was evidence of packets making it
past the checksum test.

(I *have*, however, seen a case where a bad card was corrupting packets that
survived not only the IP header check but the UDP checksum as well!  (Yes,
UDP checksums were enabled. ;-)  However, for each packet that snuck through,
tens of thousands failed, as you might imagine.  But if it's a busy NFS
server...)