Date: Sun, 01 Nov 2020 19:48:45 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "Carsten =?utf-8?q?B=C3=A4cker?=" <carbaecker@gmx.de> Cc: "John-Mark Gurney" <jmg@funkthat.com>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <DF9D466D-BF09-427F-A781-9FF6D31EF274@FreeBSD.org> In-Reply-To: <f2a38b96-917b-c723-f44f-043abe6c4629@gmx.de> 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> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <f2a38b96-917b-c723-f44f-043abe6c4629@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Oct 2020, at 16:06, Carsten Bäcker wrote: > Am 29.10.2020 um 22:39 schrieb Kristof Provost: >> >> On 29 Oct 2020, at 22:36, John-Mark Gurney wrote: >> >> 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. >> >> It does seem to do RX offload, and the comments in the driver suggest >> some .. ahem, creative hardware behaviour: >> >> |/* The checksum appears to be simplistically calculated * over the >> udp/tcp header and data up to the end of the * eth frame. Which means >> if the eth frame is padded * the csum calculation is incorrectly >> performed over * the padding bytes as well. Therefore to be safe we * >> ignore the H/W csum on frames less than or equal to * 64 bytes. * * >> Ignore H/W csum for non-IPv4 packets. */ | >> >> It’s not impossible that there’s some more issues like that in >> the >> hardware, or even that there are different chip revisions out there. >> >> That also matches up with |ifconfig ue0 -rxcsum| fixing things. >> >> Best regards, >> Kristof >> > Hello again, > > just gave it another try, using "ping heise.de" (twice) from within > the > jail. > > This is the output of tcpdump: > # tcpdump -i pflog0 -vv > tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), > capture size 262144 bytes > 14:06:04.293996 IP (tos 0x0, ttl 64, id 19576, offset 0, flags [none], > proto UDP (17), length 54) > PC-192-168-178-3.fritz.box.52421 > fritz.box.domain: [bad udp > cksum > 0xe589 -> 0x0a2c!] 64654+ A? heise.de. (26) > > Netstat: > # netstat -s -p udp | grep checksum > 4 with bad checksum > 0 with no checksum > > Packet-capture from the router is attached. > Okay… but that doesn’t actually demonstrate anything at all. It shows an outbound packet with an incorrect checksum. See what I’ve mentioned before about checksums potentially being calculated by hardware. Given that there’s been a reply to that DNS query the checksum clearly got set correctly after the packet was captured. Best, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DF9D466D-BF09-427F-A781-9FF6D31EF274>