On Dec 21,  4:40am, "Garrett D'Amore" wrote:
} 
} I've been working on Solaris, and recently added hardware checksum to
} hme.  In the course of this, it became known to me that NetBSD's hme
} driver suffers from a flaw (same as mine) involving hardware checksum
} (tx side) with tiny packets.  The checksum code is busted for packets
} less than 64-bytes in length, due to a limitation in the controller.

     When you say "packets less than 64-bytes in length," what parts of
the packet are you counting?  Ethernet packets must be a minimum of
64-bytes in length including the MAC header and FCS.

} Someone might want to look into falling back to software checksum if the
} packet to be sent is less than 64-bytes on hme hardware.
} 
} Another problem, and this probably occurs with all Sun NICs (hme, gem,
} etc.) is that partial checksum doesn't consider UDP vs TCP semantics
} when the checksum calculation returns a zero value.
} 
} The RFC for UDP says that in this case 0xffff should be substituted for
} the 0 value checksum.  For TCP the original zero is passed unmodified
} (passing 0xffff is toxic to some TCP implementations.)

     Hmm, if you consider this to be important then you can't do
hardware checksum.  The other option is to simply ignore it since a UDP
checksum of 0x0000 won't (generally) cause bad things to happen.  Or,
are you saying that the NIC will send 0xffff for both UDP and TCP
packets?

} I'm not sure what we are going to do about this in Solaris land right
} now, but I wanted to make the problem known to NetBSD, since I think it
} is impacted by this.

     Thanks.

}-- End of excerpt from "Garrett D'Amore"