There really needs to be a change in TCP/IP RFQs v.s. local area networks
now that Ethernet is no longer the BW limiting item.
Something like:
(1) A checksum of zero means don't check the checksum.
(2) You can't route a zero-checksum IP packet. If you route it,
you must checksum it before routing.
It was an allowed "feature" of UDP for a long time, and promptly more
recent RFCs severely frown upon it.
This would allow LANs to operate at higher speeds where a hardware CRC
makes sure the data is good anyway, while maintaining compatibility
outside the local area. This would also put the total responsibility
for the IP checksum with the routers which are designed for it, or
slow communications links like PPP, ISDN, and T1, that are so slow
the additional overhead is lost in the noise.
No thanks, I and several others have seen hardware fail to verify the
CRC correctly. Packet corruption happens on your local network more
than you would like to believe.
Even Linus himself saw this in amusing incident while still back in
Finland. The LAN's NFS server at the universiry, on the network where
he did his kernel work, was a Sun machine which skipped the checksums
as you describe for UDP, and when a few weeks after new ethernet card
was put into the NFS server, his kernel tarballs would become
mysteriously corrupted with single bit errors here and there.
Linus and myself had thought it was a bug in Linux, but later it was
shown that the network card in the Sun NFS server would let packets
through which had gotten corrupted and the networking stack bypassed
verifying the checksum and then boom.
Later,
David S. Miller
davem@redhat.com
-
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/