Problem with checksum offloading on RPi3 (PF + Jails involved)

[Carsten Bäcker]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rxcsum.pcap
Type: application/octet-stream
Size: 276 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20201031/5b489104/attachment.obj>