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

Kristof Provost kp at FreeBSD.org
Thu Oct 29 21:39:41 UTC 2020



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


More information about the freebsd-arm mailing list