[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231208141712.GA1674809@ZenIV>
Date: Fri, 8 Dec 2023 14:17:12 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: David Laight <David.Laight@...lab.com>
Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
gus Gusenleitner Klaus <gus@...a.com>,
Al Viro <viro@....linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
"dsahern@...nel.org" <dsahern@...nel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC][PATCHES v2] checksum stuff
On Fri, Dec 08, 2023 at 12:04:24PM +0000, David Laight wrote:
> I've just read RFC 792 and done some experiments.
> The kernel ICMP checksum code is just plain broken.
>
> RFC 792 is quite clear that the checksum is the 16-bit ones's
> complement of the one's complement sum of the ICMP message
> starting with the ICMP Type.
>
> The one's complement sum of 0xfffe and 0x0001 is zero (not the 0xffff
It is not. FYI, N-bit one's complement sum is defined as
X + Y <= MAX_N_BIT ? X + Y : X + Y - MAX_N_BIT,
where MAX_N_BIT is 2^N - 1.
You add them as natural numbers. If there is no carry and result
fits into N bits, that's it. If there is carry, you add it to
the lower N bits of sum.
Discussion of properties of that operation is present e.g. in
RFC1071, titled "Computing the Internet Checksum".
May I politely suggest that some basic understanding of the
arithmetics involved might be useful for this discussion?
Powered by blists - more mailing lists