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

"Kristof Provost" <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm,gmane.os.freebsd.devel.hackers
Message-ID <[email protected]>

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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.