Re: [dpdk-stable] [dpdk-dev] [PATCH] bugfix: udptcp_checksum should tread tcp and udp differently

["Morten Brørup" <mb@smartsharesystems.com>]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Wednesday, May 27, 2020 5:03 PM
> 
> On Wed, 27 May 2020 22:41:27 +0800
> guohongzhi <guohongzhi1@huawei.com> wrote:
> 
> > +	/* For Udp, if the computed checksum is zero,
> > +	 * it is transmitted as all ones.RFC768
> > +	 */
> > +	if (cksum == 0 && ipv4_hdr->next_proto_id == IPPROTO_UDP)
> >  		cksum = 0xffff;
> >
> 
> 
> The comment should be reformatted to be clearer.
> 
> Maybe:
> 	/*
> 	 * Per RFC768:
> 	 * If the computed  checksum  is zero,it is transmitted  as all
> ones
> 	 * (the equivalent  in one's complement  arithmetic).
> 	 */
> 

But without the double spaces. :-)

> There is no special case required here, it is true for TCP as well.

I disagree. I researched this topic when Hongzhi Guo initially submitted the patches, and have only seen the special exception mentioned in RFC 768 (describing UDP), where a transmitted value of 0x0000 means that the checksum has not been generated. None of the RFCs regarding Internet Checksum or TCP checksum mentions this special case.

> In TCP it appears 0 is allowed but not generally used. Most
> implementations
> use common checksum for both TCP and UDP

Then most implementations are wrong.

Jon Postel famously wrote: "Be liberal in what you accept, and conservative in what you send."

This function is in the transmission path, so we should calculate it correctly.

In the receive path, when checking the checksum as described in RFC 1071, any of the two values (0x0000 or 0xFFFF) in the Checksum field will yield the correct result. Which is why most implementations can get away with doing it wrong.