From owner-freebsd-net@FreeBSD.ORG Wed May 7 08:37:52 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 AADBE901; Wed, 7 May 2014 08:37:52 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 761DC982; Wed, 7 May 2014 08:37:52 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id lj1so868560pab.28 for ; Wed, 07 May 2014 01:37:52 -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=rTkUFd3928kYv/gHQ8imi5fd+k1T/7Csd54nknLvZ4s=; b=hElT+KmLCS2yrHrYMIFIxom44MS+iKwEsRgoqw87N6ZRo2up2PyYe+CfqnCzfj9WBT sdeq7q83HvtXINmFydxFz0RxQE1kj+aPgGCuW4BMGbVy0eAdGSNQq8QxkfCSuiKFZGi8 u6CWpKpD7u+OPsSSsoV0wzI9z8t0EtgGWd3d6kpWQa++roNEx8dIBVZHbZNHitBEwV6t YRIxPIlVEjWTKCnbt29INTcbnaj3FX5C3cCPL9jYWy2cPw92VMivTbhQw3NCAZ/yHT1a dGEuJ98jGwo6Bjp92GhTkJVJi+kKRIx8KQi9gFZJ6QTis2IOjyG290bHN1gbeNmeD9g9 p5gw== X-Received: by 10.66.148.70 with SMTP id tq6mr16550538pab.56.1399451871838; Wed, 07 May 2014 01:37:51 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id gj9sm1908440pbc.7.2014.05.07.01.37.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 May 2014 01:37:51 -0700 (PDT) X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 07 May 2014 17:37:51 +0900 From: Yonghyeon PYUN Date: Wed, 7 May 2014 17:37:51 +0900 To: Michael Tuexen Subject: Re: RX checksum offloading problem Message-ID: <20140507083751.GB1376@michelle.cdnetworks.com> Reply-To: pyunyh@gmail.com References: <0EB8F4F6-65C2-4B90-8101-FCC53A15C6F9@lurchi.franken.de> <20140507075612.GA1376@michelle.cdnetworks.com> <36469814-FAC8-4172-A792-487E2AB8ECB9@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36469814-FAC8-4172-A792-487E2AB8ECB9@lurchi.franken.de> 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 08:37:52 -0000 On Wed, May 07, 2014 at 10:07:09AM +0200, Michael Tuexen wrote: > On 07 May 2014, at 09:56, Yonghyeon PYUN wrote: > > > 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 > Same for me... > > 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. > Let me check this. Is there a tool to send UDP/TCP with IP level options > or do I need to write a small test program myself? > I recall I used buggy ipsend of ipfilter package in the past but it would be more easy to write a simple test program or patch driver to generate those frames.