TCP Checksum Offloading in Ethernet Card

On every HP machine we have that uses a gigabit ethernet card with TCP
checksum offloading in hardware, sniffer traces report continuous TCP
checksum errors. That's a nice oxymoron. Someone else explained that
this is considered normal behavior, and that when the TCP checksum is
checked in hardware, the software level checksums report errors.

This I don't understand at all. If the checksum matches, it matches, and
what does it matter if the checking is being done in hardware, in the
Windows kernel, or by a software application (a sniffer)? I cannot
understand why you would get different results in the hardware compared
against the sniffer application.

I find huge numbers of TCP checksum error messages incredibly distracting in
a sniffer trace, so much so that I have to turn off the hardware TCP
checksum features in the card's driver settings. Obviously I would like
any performance benefits that doing the checksums in hardware might offer,
so I would appreciate understanding this issue better. Maybe there is a
way to do the checksums in hardware and not get errors in the sniffer?

--
Will

I am also seeing many TCP checksum error FROM a Windows SQL server with an HP
Gigabit NIC. I'm also seeing the same errors FROM some of the WIN2k clients
but not as often. (There are no physical errors being reported on either
end.) I thought the "reliable" transport of TCP/IP data was a key reason for
its deployment. If the checksum is wrong what part of the MS 'stack' software
is responsible for requesting a re-transmission or is it the application
that's supposed to check? The Sniffer is reporting the same errors as
Ethereal/Wireshark. This is NOT normal behavior. The Wireshark software
indicates "(may be caused by checksum offloading?)". Can anyone help?

"Will" wrote:

> On every HP machine we have that uses a gigabit ethernet card with TCP
> checksum offloading in hardware, sniffer traces report continuous TCP
> checksum errors. That's a nice oxymoron. Someone else explained that
> this is considered normal behavior, and that when the TCP checksum is
> checked in hardware, the software level checksums report errors.
>
> This I don't understand at all. If the checksum matches, it matches, and
> what does it matter if the checking is being done in hardware, in the
> Windows kernel, or by a software application (a sniffer)? I cannot
> understand why you would get different results in the hardware compared
> against the sniffer application.
>
> I find huge numbers of TCP checksum error messages incredibly distracting in
> a sniffer trace, so much so that I have to turn off the hardware TCP
> checksum features in the card's driver settings. Obviously I would like
> any performance benefits that doing the checksums in hardware might offer,
> so I would appreciate understanding this issue better. Maybe there is a
> way to do the checksums in hardware and not get errors in the sniffer?
>
> --
> Will
>
>
>

"Ben65" <(E-Mail Removed)> wrote in message
news:8EC72733-14BA-449D-AB95-(E-Mail Removed)...
> I am also seeing many TCP checksum error FROM a Windows SQL server with an
HP
> Gigabit NIC. I'm also seeing the same errors FROM some of the WIN2k
clients
> but not as often. (There are no physical errors being reported on either
> end.) I thought the "reliable" transport of TCP/IP data was a key reason
for
> its deployment. If the checksum is wrong what part of the MS 'stack'
software
> is responsible for requesting a re-transmission or is it the application
> that's supposed to check? The Sniffer is reporting the same errors as
> Ethereal/Wireshark. This is NOT normal behavior. The Wireshark software
> indicates "(may be caused by checksum offloading?)". Can anyone help?

I think we will be opening up a trouble ticket with Microsoft on this.
Posting on various online forums simply gets confirmation like yours that it
happens. Some users insist it is normal behavior with hardware doing the
checksums, but I still don't understand why that should happen.

Application never checks the checksum when TCP is involved. That's the
whole reason to use TCP is that integrity and ordering of packets is done
for you by the TCP layer.

--
Will


> "Will" wrote:
> > On every HP machine we have that uses a gigabit ethernet card with TCP
> > checksum offloading in hardware, sniffer traces report continuous TCP
> > checksum errors. That's a nice oxymoron. Someone else explained
that
> > this is considered normal behavior, and that when the TCP checksum is
> > checked in hardware, the software level checksums report errors.
> >
> > This I don't understand at all. If the checksum matches, it matches,
and
> > what does it matter if the checking is being done in hardware, in the
> > Windows kernel, or by a software application (a sniffer)? I cannot
> > understand why you would get different results in the hardware compared
> > against the sniffer application.
> >
> > I find huge numbers of TCP checksum error messages incredibly
distracting in
> > a sniffer trace, so much so that I have to turn off the hardware TCP
> > checksum features in the card's driver settings. Obviously I would
like
> > any performance benefits that doing the checksums in hardware might
offer,
> > so I would appreciate understanding this issue better. Maybe there is
a
> > way to do the checksums in hardware and not get errors in the sniffer?
> >
> > --
> > Will