From owner-freebsd-net@FreeBSD.ORG Wed May 7 07:56:14 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 72B71E42; Wed, 7 May 2014 07:56:14 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DD962C8; Wed, 7 May 2014 07:56:14 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id y10so735632pdj.25 for ; Wed, 07 May 2014 00:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NcQnkaqDYAbL4O52JFBe/nvQHR+QqtYnNjBNlZLThCE=; b=VTGeW3azwbIJgrj4Lho854PM9jANncHynB8Qsp4+VbCc0gXnWlY+707BL9IezYPQOP Bp+ugv8yxKM6ahmC3lU7JwgMu4tYXX2DVOpem5+qgy+oPpbhyNwD9qDGtty1C9jUqtr0 0IkBTJpjEMKIa150gw326lggCiGHvwhJ0+E9l1wOkpFk07Kz5ISy6g9z1KXy8Sm6atCU +tDscrineQ/PsEAQq4su1cjaSeGBaghPKoohjDM/yCeTJJy7SWh6jweQb2zuN1QFGLiE IeEdvQfPYKdtvTG0eBVl3CkO0UmrrgCHRWDWXREPJKMLvdM+zYJV7QmKwap8UhQoU/FW 4uKA== X-Received: by 10.66.121.131 with SMTP id lk3mr16058157pab.61.1399449373546; Wed, 07 May 2014 00:56:13 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id io8sm1655920pbc.96.2014.05.07.00.56.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 May 2014 00:56:12 -0700 (PDT) X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 07 May 2014 16:56:12 +0900 From: Yonghyeon PYUN Date: Wed, 7 May 2014 16:56:12 +0900 To: Michael Tuexen Subject: Re: RX checksum offloading problem Message-ID: <20140507075612.GA1376@michelle.cdnetworks.com> Reply-To: pyunyh@gmail.com References: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:56:14 -0000 On Sat, May 03, 2014 at 11:52:47AM +0200, Michael Tuexen wrote: > On 02 May 2014, at 16:02, Bjoern A. Zeeb wrote: > > > > > On 02 May 2014, at 10:22 , Michael Tuexen wrote: > > > >> 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. > > > > 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 went through the list of drivers and you are right, it seems to be a bug > in if_smsc.c. Most of the other drivers check for UDP/TCP, a small set I can't tell. > I'm not sure how the controller computes TCP/UDP checksum values. It seems the publicly available data sheet was highly sanitized so it was useless to me. The comment in the driver says that the controller computes RX checksum after the IPv4 header to the end of ethernet frame. After seeing that comment, three questions popped up: 1. Is the controller smart enough to skip IP options header in TCP/UDP checksum offloading? 2. How controller handles UDP checksum value 0x0000(i.e. sender didn't compute UDP checksum)? 3. How the controller can compute TCP checksum of fragmented packets? Since you have the controller I guess it's easy to verify all cases. For case 3, I believe the controller can't handle fragmented frames so driver should have to explicitly check ip_off field of IPv4 header. See how gem(4)/sk(4)/hme(4) and fxp(4) handle it. > Best regards > Michael > > > > > > ? > > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > > > >