netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Noe <dpn@isomerica.net>
To: "Toralf Förster" <toralf.foerster@gmx.de>
Cc: netdev@vger.kernel.org
Subject: Re: tx-checksumming for an Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile)
Date: Thu, 27 Mar 2008 08:00:28 -0400	[thread overview]
Message-ID: <47EB8C5C.7060007@isomerica.net> (raw)
In-Reply-To: <200803271144.52812.toralf.foerster@gmx.de>

Toralf Förster wrote:
> I'm wondering why I have to add this line in my startup scripts : 
> 
> $> /usr/sbin/ethtool -K eth0 tx off
> to avoid that all outgoing packets have bad check sums (seen with wireshark).

TCP Checksum offloading defers calculation of the TCP checksums in 
software, instead passing it off to the card which calculates and 
inserts the checksums.  This is done for performance reasons - it 
offloads the CPU and lets the NIC hardware perform the relatively 
mundane task of calculating the checksum (probably also a battery 
improvement in your mobile case).

The problem is Wireshark (and other capture software) sees the outgoing 
packets before they go to the hardware and have the correct checksum 
calculated.  So Wireshark complains about invalid checksums.  There are 
a few solutions:

1) Ignore it.  You know the invalid checksums aren't an issue, just 
ignore them.  The problem is Wireshark by default highlights them in 
bright, bright red...

2) Tell Wireshark not to verify the checksums.  See 
http://wiki.wireshark.org/TCP_Checksum_Verification.  This works if you 
don't really care about the checksums and are looking at other things. 
If you suspect incorrect checksums, you can always turn off checksum 
offloading manually.

3) Use a hub (if you still have one lying around :) or a switch with a 
monitoring port.  That way you have Wireshark running on a neutral third 
system which is not part of the TCP conversation at all and thus will 
see the correct checksums as calculated by the hardware on both ends. 
This is also the only real solution if you want to check that the 
hardware is calculating the checksum correctly.

Number 3 is best, but solution 2 is fine if you don't need to know about 
the checksums.

Hope that helps.

Cheers,
Dan

-- 
                     /--------------- - -  -  -   -   -
                    |  Daniel Noe
                    |  http://isomerica.net/~dpn/

  parent reply	other threads:[~2008-03-27 12:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 10:44 tx-checksumming for an Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) Toralf Förster
2008-03-27 11:01 ` David Miller
2008-03-27 12:00 ` Daniel Noe [this message]
2008-03-27 12:14   ` Toralf Förster
2008-04-21  3:57   ` Herbert Xu
2008-04-21  4:24     ` David Miller
2008-04-21  4:50       ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47EB8C5C.7060007@isomerica.net \
    --to=dpn@isomerica.net \
    --cc=netdev@vger.kernel.org \
    --cc=toralf.foerster@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).