Date: Thu, 29 Oct 2020 21:30:14 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "Carsten =?utf-8?q?B=C3=A4cker?=" <carbaecker@gmx.de> Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> In-Reply-To: <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Oct 2020, at 16:30, Carsten Bäcker wrote: > Sure, i am willing to help. > > Device is a Raspberry Pi 3B (not +), using the onboard-ethernet. > I attached a bunch of information. > > Configuration is stripped down to the minimum required to reproduce > the > problem. > Okay, so that’s an SMC2 LAN9514_ETH device. That’s the dev/usb/net/if_smsc.c driver. However, before we dig into that driver we should make sure that we’re really looking at a checksum problem. It’s entirely normal for TX checksums to be incorrect when logged on the sending host itself (if the hardware does checksum offloading the checksum in the packet sent to the MAC is incorrect, and left to the hardware to fix). So, can you confirm that the `"[bad udp cksum 0xe58a -> 0x482d!]` you reported was on an inbound packet? And let’s be safe: try to capture packets on a different machine. That’ll give us the true packet, after the hardware has done checksum calculations. Best regards, Kristof From owner-freebsd-arm@freebsd.org Thu Oct 29 21:36:26 2020 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A77BC45E846; Thu, 29 Oct 2020 21:36:26 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CMdzt0zZCz4MwF; Thu, 29 Oct 2020 21:36:25 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 09TLaNh1031842 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Oct 2020 14:36:23 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 09TLaNTM031841; Thu, 29 Oct 2020 14:36:23 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 Oct 2020 14:36:23 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Kristof Provost <kp@FreeBSD.org> Cc: Carsten =?iso-8859-1?Q?B=E4cker?= <carbaecker@gmx.de>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201029213622.GM31099@funkthat.com> Mail-Followup-To: Kristof Provost <kp@FreeBSD.org>, Carsten =?iso-8859-1?Q?B=E4cker?= <carbaecker@gmx.de>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 29 Oct 2020 14:36:23 -0700 (PDT) X-Rspamd-Queue-Id: 4CMdzt0zZCz4MwF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2020 21:36:26 -0000 Kristof Provost wrote this message on Thu, Oct 29, 2020 at 21:30 +0100: > On 29 Oct 2020, at 16:30, Carsten Bäcker wrote: > > Sure, i am willing to help. > > > > Device is a Raspberry Pi 3B (not +), using the onboard-ethernet. > > I attached a bunch of information. > > > > Configuration is stripped down to the minimum required to reproduce > > the > > problem. > > > Okay, so that???s an SMC2 LAN9514_ETH device. > That???s the dev/usb/net/if_smsc.c driver. > > However, before we dig into that driver we should make sure that we???re > really looking at a checksum problem. > It???s entirely normal for TX checksums to be incorrect when logged on > the sending host itself (if the hardware does checksum offloading the > checksum in the packet sent to the MAC is incorrect, and left to the > hardware to fix). > > So, can you confirm that the `"[bad udp cksum 0xe58a -> 0x482d!]` you > reported was on an inbound packet? And let???s be safe: try to capture > packets on a different machine. That???ll give us the true packet, after > the hardware has done checksum calculations. One interesting point is that the smsc driver claims to not do TX offload, and a brief check shows that it doesn't allow a user to set the TXCSUM. I was thinking that the bad checksum might be due to tcpdump just complaining. does netstat -s show packets being received w/ bad checksums? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3890336-BE8F-438C-8C3E-7B21FB729FCA>