From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 10 07:26:17 2007 Return-Path: X-Original-To: freebsd-bugs@freebsd.org Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E771316A401 for ; Tue, 10 Apr 2007 07:26:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id A312F13C468 for ; Tue, 10 Apr 2007 07:26:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1197094pyh for ; Tue, 10 Apr 2007 00:26:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=l9LtN+sxGhOJLxTxd1shn7iNIM+aWUXHBZAbZrjEuA0UZBkcDiDYv3HLKJ3F1SBGxsLYzKFITsGkC8d4rJCBZthDjTv/4zlg0FwZCsd15XfsVnvNq5pOfTwCiY+yLZuj9+voe0Vfxuon5FeDdf9YqsHTH3nd9+UKKt5csRkrZfg= 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=Cr8c2199iiRf3+KdrhTRJjNWPYHqe4kBUFrysE5B3mGcBFkSU08KhJqLZjnQCjbtZHTxwwRcvhwLKYegWWYHb8ccyUwDlHUzI1Ins9b30B04qgSvJ/xz4Ivqu70OCZ5NVyZyM0W3key9wt9XXsvcY/gKpme8EAXA1XpM5F92E4E= Received: by 10.65.192.16 with SMTP id u16mr13589448qbp.1176189976994; Tue, 10 Apr 2007 00:26:16 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 8sm2388279nzn.2007.04.10.00.26.14; Tue, 10 Apr 2007 00:26:15 -0700 (PDT) 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 l3A7Rpr6047468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 16:27:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3A7Rpal047467; Tue, 10 Apr 2007 16:27:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 10 Apr 2007 16:27:51 +0900 From: Pyun YongHyeon To: Harald Schmalzbauer Message-ID: <20070410072751.GC45776@cdnetworks.co.kr> References: <200704082120.l38LKA3v058525@freefall.freebsd.org> <20070409062618.GA41379@cdnetworks.co.kr> <20070410012323.GB45776@cdnetworks.co.kr> <200704100812.50206.harry@schmalzbauer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704100812.50206.harry@schmalzbauer.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-bugs@freebsd.org Subject: Re: kern/111384: msk hw checksum problem X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 07:26:18 -0000 On Tue, Apr 10, 2007 at 08:12:49AM +0200, Harald Schmalzbauer wrote: > Am Dienstag, 10. April 2007 schrieb Pyun YongHyeon: > > On Mon, Apr 09, 2007 at 03:26:18PM +0900, To Harald Schmalzbauer wrote: > > > On Sun, Apr 08, 2007 at 09:20:10PM +0000, Harald Schmalzbauer wrote: > > > > The following reply was made to PR kern/111384; it has been noted by > > > > GNATS. > > > > > > > > From: Harald Schmalzbauer > > > > To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org > > > > Cc: > > > > Subject: Re: kern/111384: msk hw checksum problem > > > > Date: Sun, 8 Apr 2007 22:58:12 +0200 > > > > > > > > I did a quick check on 6.2-stable and couldn't see the symptom (no > > > > connection to freeshports). But I haven't captured traffic, so I > > > > can't guarantee that the "TCP checksum mismatch" doesn't aplly to > > > > 6.2-stable as well. > > > > > > Hmm, it's odd that STABLE works wihtout issues. msk(4) in STABLE > > > takes the same code path so it shoud have the issue too if msk(4) in > > > HEAD also has checksum offload issues. > > > > > > The reason of sending Winwdos probe message comes from the other > > > party' zero window advertisement in SYN + ACK packet. As you know > > > TCP can't send more data except window probing message if it recevied > > > zero window advirtisement. > > > Maybe the other party(www.freshports.org) advertise its window update > > > packet if it received correct window probe message from msk(4). > > > Since msk(4) failed to generate correct TCP cheksum the other party > > > didn't receive the probe message and you've lost connection here. > > > > > > Anyway I was able to reproduce the issue on HEAD but I have no idea > > > atm. Just padding with zeros to make it 60 bytes frame didn't work and > > > I wonder how it could work in STABLE. > > > > Please try attached patch and let me know the result. > > Hello Pyun YongHyeon, > > thank you, I applied your patch and it does fix the symptom, but I still > get "TCP checksum incorrect": If you've collected dump data on host 172.21.1.0 it's normall to see corrupted checksum because the hardware will compute the checksum later. If you've captured the traffic on gateway machine it would be real error. However I don't think you've captured the data on gateway machine as you appaers to get access to freshports.org. > No. Time Source Destination Protocol Info > 1 0.000000 172.21.1.0 64.147.113.42 TCP 51502 > > http [SYN] Seq=0 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=8 TSV=313925 > TSER=0 > > Frame 1 (74 bytes on wire, 74 bytes captured) > Ethernet II, Src: Giga-Byt_80:cd:51 (00:16:e6:80:cd:51), Dst: Olicom_c0:33:71 > (00:00:24:c0:33:71) > Internet Protocol, Src: 172.21.1.0 (172.21.1.0), Dst: 64.147.113.42 > (64.147.113.42) > Transmission Control Protocol, Src Port: 51502 (51502), Dst Port: http (80), > Seq: 0, Len: 0 > Source port: 51502 (51502) > Destination port: http (80) > Sequence number: 0 (relative sequence number) > Header length: 40 bytes > Flags: 0x02 (SYN) > Window size: 65535 > Checksum: 0x5f01 [incorrect, should be 0xc37c (maybe caused by "TCP > checksum offload"?)] > [Good Checksum: False] > [Bad Checksum: True] > Options: (20 bytes) > > I'll see if the msk watchdog problem I had seen before (my /home is nfs (over > TCP) mounted) comes back since I have enabled txcsum again. If you see msk(4) watchdog problem again open a new PR for the watchdog issue. > Today I'm out of office so "realf life" results are only possible in the > evening! > > Thanks, > Thanks for reporting and testing. > -Harry -- Regards, Pyun YongHyeon