Date: Tue, 3 Nov 2020 09:46:08 +0100 From: Hans Petter Selasky <hps@selasky.org> To: YongHyeon PYUN <pyunyh@gmail.com>, Kristof Provost <kp@FreeBSD.org> Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> In-Reply-To: <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------812ED0F32473780BBAF6ADAC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2020-11-03 09:19, Hans Petter Selasky wrote:
> 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).
>
> <---------------------------- actlen
> -------------------------------------------------->
> <------------- pktlen ------------------------>
> rxhdr(4 bytes) | padding (2 bytes) | RX frame | FCS(4 bytes) | partial
> checksum(2 bytes)
Hi,
I wonder if the checksum is zero, when not valid, and that we should
check for this in the driver!
Can you try this patch?
Also enabling debugging in the SMSC driver would be useful.
--HPS
--------------812ED0F32473780BBAF6ADAC
Content-Type: text/x-patch; charset=UTF-8;
name="smsc.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="smsc.diff"
Index: sys/dev/usb/net/if_smsc.c
===================================================================
--- sys/dev/usb/net/if_smsc.c (revision 367268)
+++ sys/dev/usb/net/if_smsc.c (working copy)
@@ -1020,7 +1020,7 @@
pktlen -= 2;
/* The checksum appears to be simplistically calculated
- * over the udp/tcp header and data up to the end of the
+ * 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
@@ -1031,27 +1031,21 @@
*/
if ((be16toh(eh->ether_type) == ETHERTYPE_IP) &&
(pktlen > ETHER_MIN_LEN)) {
- struct ip *ip;
+ /* Copy the TCP/UDP checksum from the last 2 bytes
+ * of the transfer and put in the csum_data field.
+ */
+ usbd_copy_out(pc, (off + pktlen), &m->m_pkthdr.csum_data, 2);
- ip = (struct ip *)(eh + 1);
- if ((ip->ip_v == IPVERSION) &&
- ((ip->ip_p == IPPROTO_TCP) ||
- (ip->ip_p == IPPROTO_UDP))) {
+ /* The data is copied in network order, but the
+ * csum algorithm in the kernel expects it to be
+ * in host network order.
+ */
+ m->m_pkthdr.csum_data = ntohs(m->m_pkthdr.csum_data);
+
+ if (m->m_pkthdr.csum_data != 0) {
/* Indicate the UDP/TCP csum has been calculated */
m->m_pkthdr.csum_flags |= CSUM_DATA_VALID;
- /* Copy the TCP/UDP checksum from the last 2 bytes
- * of the transfer and put in the csum_data field.
- */
- usbd_copy_out(pc, (off + pktlen),
- &m->m_pkthdr.csum_data, 2);
-
- /* The data is copied in network order, but the
- * csum algorithm in the kernel expects it to be
- * in host network order.
- */
- m->m_pkthdr.csum_data = ntohs(m->m_pkthdr.csum_data);
-
smsc_dbg_printf(sc, "RX checksum offloaded (0x%04x)\n",
m->m_pkthdr.csum_data);
}
--------------812ED0F32473780BBAF6ADAC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4dfaa9a3-c085-8466-a6e4-19f988b5ed3d>