From owner-freebsd-net@FreeBSD.ORG Fri May 2 10:22:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F366A753 for ; Fri, 2 May 2014 10:22:31 +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 B957A15C7 for ; Fri, 2 May 2014 10:22:31 +0000 (UTC) Received: from [192.168.1.200] (p548190F2.dip0.t-ipconnect.de [84.129.144.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EFDA31C104913 for ; Fri, 2 May 2014 12:22:27 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RX checksum offloading problem Message-Id: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> Date: Fri, 2 May 2014 12:22:25 +0200 To: FreeBSD Net Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) 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 10:22:32 -0000 Dear all, 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. 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. 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. Now the following happens (on the raspberry pi the driver used is dev/usb/net/if_smsc.c 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. Alternatives to fix this: 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. 2. Map CSUM_DATA_VALID to some other generic value in mbuf.h. However, = CSUM_L4_CALC, which would make perfect sense in my view, is already used for = CSUM_PSEUDO_HDR. Therefore we would have to define a new generic value. So what is the best way to fix this? Best regards Michael=