From owner-freebsd-net@FreeBSD.ORG Mon May 12 01:45:08 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 F0CD92AF; Mon, 12 May 2014 01:45:08 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 B90452A0A; Mon, 12 May 2014 01:45:08 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz1so7173440pad.16 for ; Sun, 11 May 2014 18:45:08 -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=h9u5zSGzUctVOzYMZzQFzS9KrTvGITLvf+UBJAeOU+Y=; b=wvbW36oeVGFDhfHg8xJqflK1aM12XHtVjj58hnoLCLMLjihnWHYvsdiE5ajb4WmBxc wIa14QGUuME0cocFAud6QfJFXTTgqT7SFNG22iqCstqscy2kBBpTLvcCOwP07Y29Rz0Z YkUQKF5qdm1LsEwQDB8QzncdrS4KHq0aHdbfWCYKmplhZ69+OyFmxmDWv0EKVh6oUDvC MfASW9POGExG/42njARcL7wM2g73p6+cRTUwTSQUAJlTyezB9a2HDE618vY9BhpvZzG6 XiepyTSPhQKmTgNOFF9eyvHlIKouXt8n6n4AxNXwkCItjXH53wYJYftgjvRi6hSUYMcl V4LA== X-Received: by 10.66.189.201 with SMTP id gk9mr49041804pac.25.1399859108400; Sun, 11 May 2014 18:45:08 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id pr4sm19763434pbb.53.2014.05.11.18.45.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 May 2014 18:45:07 -0700 (PDT) X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 May 2014 10:45:02 +0900 From: Yonghyeon PYUN Date: Mon, 12 May 2014 10:45:02 +0900 To: Michael Tuexen Subject: Re: RX checksum offloading problem Message-ID: <20140512014502.GB4085@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> <20140507083751.GB1376@michelle.cdnetworks.com> <415C1CB5-3AF9-44E4-943A-74116037980E@lurchi.franken.de> <20140509013556.GA3014@michelle.cdnetworks.com> 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: Mon, 12 May 2014 01:45:09 -0000 On Fri, May 09, 2014 at 04:22:36PM +0200, Michael Tuexen wrote: > > On 09 May 2014, at 12:46, Michael Tuexen wrote: > > > On 09 May 2014, at 03:35, Yonghyeon PYUN wrote: > > > >> On Thu, May 08, 2014 at 08:40:22PM +0200, Michael Tuexen wrote: > >>> On 07 May 2014, at 10:37, Yonghyeon PYUN wrote: > >>> > >>>> 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: > >>>>>> > >>> OK, I did some testing. It looks like the card is just computing the > >>> checksum over the IP payload taking the correct IP header length into account. > >>>>>> 1. Is the controller smart enough to skip IP options header in > >>>>>> TCP/UDP checksum offloading? > >>> Yes, I can send fragmented and un-fragmented UDP packets with IP options > >>> and they are handled correctly. Even if the last fragment is too short. > >> > >> I'm assuming you're taking about receiving fragmented UDP packets > >> with RX checksum offloading, right? > > Correct. > >> > >>>>>> 2. How controller handles UDP checksum value 0x0000(i.e. sender > >>>>>> didn't compute UDP checksum)? > >>> This case isn't handled. However, udp_input() looks first for zero checksums > >>> and only after that in the csum_flags. So it doesn't result in any problems. > >>> Would you prefer not to set CSUM_DATA_VALID in this case? > >> > >> At least, it correctly updates UDP stats of netstat(1). > > Let me double check that... > I double checked it. The statistic counters are incremented. > Please note that we had a bug in the sending code of head, which > made it impossible to send UDP packets with 0 checksum. That is > fixed in > http://svnweb.freebsd.org/base?view=revision&revision=265776 Thanks. > > So any preference whether to report CSUM_DATA_VALID if a UDP packet > with checksum 0 is received or not? I'm pretty open, since it does > not have any effect right now... > Because upper stack correctly counts for these packets, your change (report CSUM_DATA_VALID for UDP packet with checksum value 0) looks fine. I don't remember how pf/ipf handles that case though but we can easily fix pf/ipf once we see breakage. > Best regards > Michael