[dpdk-dev] Bug in IPv4 header checksum computation?

[Olivier Matz]

Hi,

On Tue, Apr 02, 2019 at 10:58:52AM +0300, Andrew Rybchenko wrote:
> Hi,
> 
> added more people in CC.
> 
> On 4/1/19 6:29 PM, N. Benes wrote:
> > Hi,
> > 
> > I wrote to the users list a bit more a week ago concerning the IPv4
> > Header Checksum computation and received no comments on it yet:
> > 
> > https://mails.dpdk.org/archives/users/2019-March/004021.html
> > https://mails.dpdk.org/archives/users/2019-March/004022.html
> > 
> > I have the impression that the current implementation wrongly does a
> > conditional final inversion of the computed sum. This is correct for
> > e.g. UDP, but I think it is not for an IPv4 Header (header checksum is
> > not optional).
> > 
> > If it is a bug, this could result in a surprisingly high number of
> > invalid/dropped IPv4 packets, when the checksum is calculated manually
> > via the DPDK API (not NIC-offloaded) and the IPv4 header has an
> > appropriate combination of values e.g. the IP Identification field.
> 
> I agree that it looks like a bug in DPDK. RFC 791 says nothing about
> avoid zero value for IPv4 checksum.
> 
> Andrew.

Thank you for reporting this. In my opinion, this operation is indeed useless,
but not a critical bug: it won't make the checksum verification to fail.
Indeed, in one's complement arithmetic, the "0" value can be either 0x0000 or
0xffff. This is why it can be safely replaced in case of UDP.

See https://en.wikipedia.org/wiki/Ones%27_complement

I will submit a patch to change this.

Regards,
Olivier