>> Another problem [...] 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.

...??  You mean there are "hardware" (often really firmware, I daresay)
checksum implementations out there that don't provide the semantics the
IP/UDP/TCP specs call for?

If so, then, well, duh you can't use them!

> The other option is to simply ignore it since a UDP checksum of
> 0x0000 won't (generally) cause bad things to happen.

I don't consider undetected data corruption to not be a "bad thing".
"Presumably this means it is important to get wrong answers quickly."

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B