netdev - Re: tx-checksumming for an Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47EB8C5C.7060007@isomerica.net>
Date:	Thu, 27 Mar 2008 08:00:28 -0400
From:	Daniel Noe <dpn@...merica.net>
To:	Toralf Förster <toralf.foerster@....de>
CC:	netdev@...r.kernel.org
Subject: Re: tx-checksumming for an Intel Corporation 82540EP Gigabit Ethernet
 Controller (Mobile)

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/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html