From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 10 06:12:59 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 0916016A402 for ; Tue, 10 Apr 2007 06:12:59 +0000 (UTC) (envelope-from harry@schmalzbauer.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD5913C465 for ; Tue, 10 Apr 2007 06:12:56 +0000 (UTC) (envelope-from harry@schmalzbauer.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l3A6CooQ090769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 08:12:56 +0200 (CEST) (envelope-from harry@schmalzbauer.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l3A6CokL065117; Tue, 10 Apr 2007 08:12:50 +0200 (CEST) (envelope-from harry@schmalzbauer.de) Received: by titan.flintsbach.schmalzbauer.de (8.13.8/8.13.8/Submit) id l3A6CoSE001504; Tue, 10 Apr 2007 08:12:50 +0200 (CEST) (envelope-from harry@schmalzbauer.de) From: Harald Schmalzbauer To: pyunyh@gmail.com Date: Tue, 10 Apr 2007 08:12:49 +0200 User-Agent: KMail/1.9.6 References: <200704082120.l38LKA3v058525@freefall.freebsd.org> <20070409062618.GA41379@cdnetworks.co.kr> <20070410012323.GB45776@cdnetworks.co.kr> In-Reply-To: <20070410012323.GB45776@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704100812.50206.harry@schmalzbauer.de> 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 List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 06:12:59 -0000 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": 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. Today I'm out of office so "realf life" results are only possible in the evening! Thanks, -Harry