en en en en en en ceb yue en en en en mk en hbs_lat ca en en en en es de en en en en en en en en en en ru es en ro en en en en en en pt es en en en oc en en en pt en en en en en en en en en en en en en en en en en en en en en en ceb yue en en en en mk en hbs_lat
Comment 1 Björn Jacke 2010-02-25 20:59:16 UTC
Comment 2 Jesse Brandeburg 2010-03-02 07:31:48 UTC
Comment 3 Björn Jacke 2010-03-03 15:32:22 UTC
06:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter (numeric:) 06:02.0 0200: 8086:1079 (rev 03) Subsystem: 8086:1179 is just another 82546GB bases card we have. It has the same checksumming bug.
Comment 4 Björn Jacke 2010-03-04 00:27:01 UTC
This Intel document about the 82543GC shows that this is a known bug: ftp://download.intel.com/design/network/specupdt/82543gc.pdf 38. Transmit TCP Checksum Incorrectly Modified if Calculated as 0x0000 Problem: If the controller calculates a transmit TCP checksum as 0x0000, it will automatically change the checksum to 0xFFFF. Specifications call for 0xFFFF be substituted for 0x0000 for UDP packets to distinguish UDP packets that carry no checksum. However, the modification does not apply to TCP packets. Implication: If the receiving station is running MS-DOS and calculates a receive checksum of 0x0000, it will flag an error if the checksum contained in the packet is 0xFFFF. Other operating systems treat 0x0000 and 0xFFFF as equivalent in one’s complement math. UDP checksums are correct. Workaround: Intel modified the DOS Ethernet driver to check for a received checksum of 0xFFFF on a TCP/IP packet and change it back to 0x0000 before passing the packet to the operating system. Status: Intel does not plan to resolve this erratum in a future stepping of the 82543GC Gigabit Ethernet Controller.
Comment 5 Björn Jacke 2010-03-04 00:31:18 UTC
so far known to be broken are 82546EB, 82546GB and 82543GC. Is there a more complete list of broken cards available?
Comment 6 Björn Jacke 2010-03-10 20:11:44 UTC
Jesse: can someone @Intel tell which chipsets are affected?
Comment 7 Björn Jacke 2012-05-13 11:10:40 UTC
the TCP checksum offloading of those cards are still broken. The bug should not get resolved as "obsolete" but be the tcp checksum offloading be blacklisted instead.
Comment 8 Tushar 2012-11-21 23:36:19 UTC
Here is the background info I found: Summary Because 0000h and FFFFh are equivalent in 1’s complement arithmetic, it will not cause problems if a checksum value of FFFFh is used instead of 0000h. Background For a UDP packet, a checksum value of 0000h means that the packet does not include a checksum. Thus, if the packet is supposed to include a checksum, and the checksum calculation happens to result in a value of 0000h, then the actual value used for the checksum field is FFFFh. The preferred method of verifying the IP, UDP or TCP checksum is to sum the covered data (in 16-bit quantities) using 1’s complement arithmetic and comparing the result to FFFFh. If it matches then the checksum is valid; otherwise it is invalid. This method is described in RFC 1071 (section 1, item 3) and in RFC 1624 (section 5). This allows the UDP checksum to be verified without the end system worrying about converting a checksum of 0000h into FFFFh. It also allows the IP and TCP checksum calculation to use this replacement. Because the values 0000h and FFFFh are equivalent in 1’s complement arithmetic, the sum will still be FFFFh for a valid checksum. In order to simplify the design, our hardware always converts a checksum value of 0000h into FFFFh. Because the RFC method accounts for this, there should be no conflict with well-written TCP/IP stacks.