kern/111384: msk hw checksum problem

[Harald Schmalzbauer]

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":
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