kern/111384: msk hw checksum problem

[Pyun YongHyeon]

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 <harry at schmalzbauer.de>
 > >  >  > To: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at 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