Date: Tue, 10 Apr 2007 08:12:49 +0200 From: Harald Schmalzbauer <harry@schmalzbauer.de> To: pyunyh@gmail.com Cc: freebsd-bugs@freebsd.org Subject: Re: kern/111384: msk hw checksum problem Message-ID: <200704100812.50206.harry@schmalzbauer.de> In-Reply-To: <20070410012323.GB45776@cdnetworks.co.kr> References: <200704082120.l38LKA3v058525@freefall.freebsd.org> <20070409062618.GA41379@cdnetworks.co.kr> <20070410012323.GB45776@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <harry@schmalzbauer.de>
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704100812.50206.harry>