Problem with checksum offloading on RPi3 (PF + Jails involved)
Kristof Provost
kp at FreeBSD.org
Tue Nov 3 08:15:58 UTC 2020
On 3 Nov 2020, at 5:52, YongHyeon PYUN wrote:
>
> I'm not sure where the root cause is but it seems smsc(4) needs
> improvement in RX checksum handling.
That’s my thinking as well, yes. I’m not quite sure how though,
because the received packet should contain full and correct checksums
regardless of the hardware’s checksum handling, so pf shouldn’t have
any issues updating checksums.
Ah, except that the driver also copies the checksum into the mbuf’s
csum_data field, and if that checksum is wrong we would indeed see pf
update an incorrect checksum, and we’d get forwarded packets with bad
checksums. That also matches with the observation that the problem goes
away when rx checksum offload is disabled.
> Quick reading RX handler
> indicates RX checksum offloading does not work when:
> o IP datagram has IP options field
> o TCP/UDP packet was fragmented
> o UDP datagrams with 0 checksum value
> See fxp(4), gem(4) and hme(4) for implementation.
>
> It looks like smsc(4) uses the following RX format but I don't
> know actual RX format of H/W(no access to datasheet).
>
Happily Microchip do publish the datasheet:
http://ww1.microchip.com/downloads/en//softwarelibrary/man-lan95xx-dat/lan9512_lan9512i%20databook%20rev.%201.2%20(03-01-12).pdf
It may indeed be the case that this happens when the IP (or TCP) header
has options, but without a clear capture (or ideally, access to a setup
to reproduce the problem) it’s hard to tell.
The datasheet has the great benefit of existing and being published, but
it does lack a bit of detail when it comes to the RX checksum offload
engine.
> <---------------------------- actlen
> -------------------------------------------------->
> <------------- pktlen ------------------------>
> rxhdr(4 bytes) | padding (2 bytes) | RX frame | FCS(4 bytes) | partial
> checksum(2 bytes)
>
> If the format above is correct smsc(4) needs more strict RX length
> validation(USB transfer size vs actual packet length). This
> indicates smsc(4) does not have to copy FCS bytes.
> Also given that H/W always appends FCS, it's also suspicious H/W
> does not correctly compute RX checksum for frames less than or
> equal to 64 bytes.
>
> I don't have H/W and some spare time to fix this though. :-(
>
Sadly I don’t have this hardware either.
Best regards,
Kristof
More information about the freebsd-hackers
mailing list