Date: Sat, 31 Oct 2020 16:06:40 +0100 From: =?UTF-8?Q?Carsten_B=c3=a4cker?= <carbaecker@gmx.de> To: Kristof Provost <kp@FreeBSD.org>, John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <f2a38b96-917b-c723-f44f-043abe6c4629@gmx.de> In-Reply-To: <55713894-A896-4F12-ABB9-93DFEB2F16B9@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> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. Best regards, Carsten [-- Attachment #2 --] 4Ͳ i |_3U ^ ^ , (mǦGK(m`4'U~p E 6| @a% 5 "!߉ heisede |_\ n n 0ǦGK(m'U~p\(m E F8 @]A 5% 2gb߉ heisede ( cPhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f2a38b96-917b-c723-f44f-043abe6c4629>