From owner-freebsd-current@FreeBSD.ORG Wed Jan 24 23:52:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7691516A400 for ; Wed, 24 Jan 2007 23:52:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 33AF613C43E for ; Wed, 24 Jan 2007 23:52:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so130088pye for ; Wed, 24 Jan 2007 15:52:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=DjnZgyzBeOy9XBbOn6r5RL+jtmQCn4PVjPavBOV61iuEvYgZ048qSrewdZ6fUVRZJJwLOM4fFkWTkJsPU2Xhn+TXL3pxOlcju5YktCom3i7+bg2uBALRLOSQSEDbxmhzBzXQ6QrK5GJOyEKP8FOLpGUbNhVU67WiQuIke5rTJ78= Received: by 10.35.126.7 with SMTP id d7mr2565072pyn.1169682773560; Wed, 24 Jan 2007 15:52:53 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id f57sm1280545pyh.2007.01.24.15.52.50; Wed, 24 Jan 2007 15:52:52 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l0ONsP37041670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 08:54:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0ONsOwm041669; Thu, 25 Jan 2007 08:54:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 25 Jan 2007 08:54:24 +0900 From: Pyun YongHyeon To: Bill Paul Message-ID: <20070124235424.GA41550@cdnetworks.co.kr> References: <45B736DE.1000100@gmail.com> <20070124190203.E80FB16A403@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124190203.E80FB16A403@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.ORG, Rene Ladan Subject: Re: Call for re(4) checksum offload testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 23:52:54 -0000 On Wed, Jan 24, 2007 at 07:02:03PM +0000, Bill Paul wrote: > > Bill Paul schreef: > > [...] > > > > > I'm very confused as to why the chip botches the TX checksumming in > > > this case. Unfortunately, most of this confusion stems from the fact > > > that you didn't specify exactly which chip rev the user with this > > > problem has, or give a test case to trip the bug. > > > > > I am that user, using this card, found in Asus A6JE laptops. From pciconf: > > > > card: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00 > > vendor=Realtek Semiconductor > > device=RTL8168/8111 PCI-E Gigabit Ethernet NIC > > > > > I'm assuming this yet another problem with small IP fragments being > > > mangled. That being the case, it should be possible to trip the bug > > > with "ping -s 1473 ." (1473 is 1 byte too large to fit into > > > a 1500 byte frame, which will cause a 1 byte fragment to be sent.) > > > I thought I tested this with my sample PCIe cards though, and didn't > > > see a problem. I'll have to try it again tomorrow. > > > > > ping -s 1473 succeeds both with and without the patch (i.e. > > ping gives timings), I've included two tcpdumps for further analysis. > > Unfortunately, these packet dumps don't help me: I need a packet dump > that shows the failure, and these don't. > > > The bug is visible when logging in to sites such as gmail.com or > > nl.bol.com (a Dutch shopping site), or when connecting Thunderbird to > > pop.gmail.com (which uses POP3 with SSL) > > Hm. Ok, apparently the TCP segments that cause the problem look like > this: > > 10:41:54.607019 00:03:47:a6:3f:c0 > 00:00:0c:07:ac:2e, ethertype IPv4 (0x0800), > length 54: 147.11.46.221.63693 > 216.239.57.83.80: . ack 1 win 65535 > > I captured this by doing 'telnet gmail.com 80' from my system at work. > I contrived a quick test where I wrote a small routine to send a packet > with exactly these contents and duplicated the problem with my sample > 8111B/8168B card (the frame isn't mangled as badly as the small IP > fragment case, but the TCP checksum is wrong). The RTL8101E (10/100) PCIe > adapter also botches the checksum in the same way. The earlier PCI cards > do not. > > Based on testing with my sample adapters, I think the right thing to do > is skip the software padding in the TCP case. It appears that even > the older 8169 adapters that botch the small IP fragment case will correctly > handle this small TCP segment case. I'm attaching a patch which should > fix the problem without breaking the workaround for other NICs. If you > verify that this patch also fixes your problem, then this patch should > be checked in instead of the other one. > Since you have the problematic hardware in hand would you verify it works for small UDP case?(i.e. 28 bytes, IP header 20 bytes, UDP header 8 bytes). If you already checked UDP case please ignore this mail. Thank you. -- Regards, Pyun YongHyeon