[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0702MB3840F2D594B9681BF2E0CD81D9D4A@VI1PR0702MB3840.eurprd07.prod.outlook.com>
Date: Thu, 19 Oct 2023 04:44:04 +0000
From: gus Gusenleitner Klaus <gus@...a.com>
To: Al Viro <viro@....linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>
CC: 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>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Subject: AW: [PATCH] amd64: Fix csum_partial_copy_generic()
> On Wed, Oct 18, 2023 at 06:18:05AM +0000, gus Gusenleitner Klaus wrote:
> > The checksum calculation is wrong in case of an source buffer
> > containing zero bytes only. The expected return value is 0, the
> > actual return value is 0xfffffff.
>
> Expected where? The actual checksum is defined modulo 0xffff, so
> 0 and 0xffffffff represent the same final value.
>
> The only twist is that in some situations we internally use 0 for
> "not calculated yet".
>
> > This problem occurs when a ICMP echo reply is sent that has set
> > zero identifier, sequence number and data.
>
> What problem? Could you please either point to specific RFC or
> show that packets are rejected by some existing system, or...?
Here's our situation:
Our device gets pinged by a third party manufacturer robot controller.
We have updated the kernel in our device to 5.15 from 4.9, the robot
controller is kept unchanged. At 4.9, our device's ping reply is accepted
by the robot controller, at 5.15 it's not.
Wireshark shows a bad checksum warning:
'Checksum: 0x0000 incorrect, should be 0xffff'
Powered by blists - more mailing lists