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

[Kristof Provost]

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