From owner-freebsd-net@FreeBSD.ORG Fri May 2 14:03:05 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 E4705E18 for ; Fri, 2 May 2014 14:03:05 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97CAA1A8C for ; Fri, 2 May 2014 14:03:05 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C6B6025D3A92; Fri, 2 May 2014 14:02:55 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 6F663C22C24; Fri, 2 May 2014 14:02:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id HuAc5kCLlcuF; Fri, 2 May 2014 14:02:52 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 7BA68C22BD4; Fri, 2 May 2014 14:02:50 +0000 (UTC) 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: "Bjoern A. Zeeb" In-Reply-To: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> Date: Fri, 2 May 2014 14:02:49 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> To: Michael Tuexen 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: Fri, 02 May 2014 14:03:06 -0000 On 02 May 2014, at 10:22 , Michael Tuexen = wrote: > 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. 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. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983