Date: Sat, 3 May 2014 10:30:23 +0200 From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: RX checksum offloading problem Message-ID: <D314A322-038E-41D3-9E0A-4B2AFD121C97@lurchi.franken.de> In-Reply-To: <A345E6A0-D6FF-4E69-AFBD-9BB67B82F02E@FreeBSD.org> References: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> <A345E6A0-D6FF-4E69-AFBD-9BB67B82F02E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02 May 2014, at 16:02, Bjoern A. Zeeb <bz@FreeBSD.org> wrote: >=20 > On 02 May 2014, at 10:22 , Michael Tuexen = <Michael.Tuexen@lurchi.franken.de> wrote: >=20 >> Dear all, >>=20 >> during testing I found that FreeBSD head (on a raspberry pi) accepts = SCTP packet >> with bad checksums. After debugging this I figured out that this is a = problem with >> the csum_flags defined in mbuf.h. >>=20 >> The SCTP code on its input path checks for CSUM_SCTP_VALID, which is = defined in mbuf.h: >> #define CSUM_SCTP_VALID CSUM_L4_VALID >> This makes sense: If CSUM_SCTP_VALID is set in csum_flags, the packet = is considered >> to have a correct checksum. >>=20 >> For UDP and TCP some drivers calculate the UDP/TCP checksum and set = CSUM_DATA_VALID in >> csum_flags to indicate that the UDP/TCP should consider csum_data to = figure out if >> the packet has a correct checksum. The problem is that = CSUM_DATA_VALID is defined as >> #define CSUM_DATA_VALID CSUM_L4_VALID >> In this case the semantic is not that the packet has a valid = checksum, but the csum_data >> field contains information. >>=20 >> Now the following happens (on the raspberry pi the driver used is >> dev/usb/net/if_smsc.c >>=20 >> 1. A packet is received and if it is not too short, the checksum = computed >> is stored in csum_data and the flag CSUM_DATA_VALID is set. This = happens >> for all IP packets, not only for UDP and TCP packets. >> 2. In case of SCTP packets, the SCTP interprets CSUM_DATA_VALID as = CSUM_SCTP_VALID >> and accepts the packet. So no SCTP checksum check ever happened. >>=20 >> Alternatives to fix this: >>=20 >> 1. Change all drivers to set CSUM_DATA_VALID only in case of UDP or = TCP packets, since >> it only makes sense in these cases. >=20 > Wait, or for SCTP in cad the crc32 (I think it was) was actually = checked but not otherwise. This is how it should be imho. It seems = like a driver bug. I'm not sure what you want to say with the first sentence. However, SCTP uses a CRC32C and most of the NICs don't support it (some = do and they do it right, as far as I know). I can go through the drivers listed in http://fxr.watson.org/fxr/ident?i=3DCSUM_DATA_VALID and make sure they only set CSUM_DATA_VALID for UDP and TCP packets... Best regards Michael >=20 >=20 > =97=20 > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, = 1983 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D314A322-038E-41D3-9E0A-4B2AFD121C97>