From owner-freebsd-net@FreeBSD.ORG Sat May 3 08:30:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D0D32BA; Sat, 3 May 2014 08:30:29 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61241135C; Sat, 3 May 2014 08:30:29 +0000 (UTC) Received: from [192.168.1.200] (p548196A1.dip0.t-ipconnect.de [84.129.150.161]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0412D1C10492E; Sat, 3 May 2014 10:30:24 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: RX checksum offloading problem From: Michael Tuexen In-Reply-To: Date: Sat, 3 May 2014 10:30:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 08:30:29 -0000 On 02 May 2014, at 16:02, Bjoern A. Zeeb wrote: >=20 > On 02 May 2014, at 10:22 , Michael Tuexen = 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