From: Olivier Matz <olivier.matz@6wind.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: "N. Benes" <nbenes@eso.org>, dev <dev@dpdk.org>,
Stephen Hemminger <stephen@networkplumber.org>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] Bug in IPv4 header checksum computation?
Date: Tue, 2 Apr 2019 10:46:29 +0200 [thread overview]
Message-ID: <20190402084629.2f3u3iqfkkmrf72x@glumotte.dev.6wind.com> (raw)
In-Reply-To: <105860ec-b4b7-b045-05e0-6fb67bab237a@solarflare.com>
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
next prev parent reply other threads:[~2019-04-02 8:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 15:29 N. Benes
2019-04-01 15:29 ` N. Benes
2019-04-02 7:58 ` Andrew Rybchenko
2019-04-02 7:58 ` Andrew Rybchenko
2019-04-02 8:46 ` Olivier Matz [this message]
2019-04-02 8:46 ` Olivier Matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190402084629.2f3u3iqfkkmrf72x@glumotte.dev.6wind.com \
--to=olivier.matz@6wind.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=nbenes@eso.org \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).