TCP/UDP Checksum Incorrect

[Alejandro]

Wireshark reports the following problems in DELL Inspiron 1526

Checksum: 0x1eba [incorrect, should be 0x404a (maybe caused by "TCP checksum offload"?)]
Checksum: 0x1e73 [incorrect, should be 0xdd14 (maybe caused by "UDP checksum offload"?)]

When trying to disable checksum

$ ethtool -k eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
rx-checksumming: off
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: on

$ sudo ethtool --offload eth0 tx off
Cannot set device tx csum settings: Operation not supported

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.10
DISTRIB_CODENAME=intrepid
DISTRIB_DESCRIPTION="Ubuntu 8.10"

$ uname -a
Linux alebalderas-laptop 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: fglrx
Package: linux-image-2.6.27-11-generic 2.6.27-11.27
ProcCmdLine: root=UUID=bcadc99b-0622-451b-99d0-e0c31ef98150 ro quiet splash
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.27-11.27-generic
SourcePackage: linux

[Jeremy Foshee (jeremyfoshee)]

Hi Alejandro,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/lucid.

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 326406

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Michael DePaulo (mikedep333)]

I am running lucid 64-bit with a Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express.
I have observed the following:
TCP checksums are always about 1/3rd incorrect regardless of tx checksum offloading
All UDP checksums are incorreft with tx checksum offloading
All UDP checksums are correct without tx checksum offloading

I tried running "apport-collect -p linux 326406" but it wouldn't let me do it because I was not the author of this bug.

[Michael DePaulo (mikedep333)]

I tested this on another computer, one running lucid 64-bit with a Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12).
I have observed the following:
TCP checksums are about 40% incorrect with tx checksum on
TCP checksums are about 25% incorrect with tx checksum off
UDP checksums are always incorrect with tx checksum on
UDP checksums are never incorrect (always correct) with tx checksum off

[ybaruss (yabruss)]

Hello,

Is this a report from Wireshark still ?

Michael DePaulo: "UDP checksums are never incorrect (always correct) with tx checksum off" => When there is no checksum control => validity is always granted ...

[ybaruss (yabruss)]

Due to lack of information I change status to Invalid.

Original complain was about Wireshark and now general purpose of UPD/TCP checksum control is out of topic.

[Michael DePaulo (mikedep333)]

ybaruss:
I just reran the wireshark test on my maverick 10.10 (latest updates) 64-bit system with a Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express.

I got the following results, which are similar to before:
TCP checksums are about 90% incorrect with tx checksum on
TCP checksums are never incorrect (always correct) with tx checksum off
UDP checksums are always incorrect with tx checksum on
UDP checksums are never incorrect (always correct) with tx checksum off

Ybaruss: I believe the bug is not in wireshark, but instead wireshark is identifying the bug in the kernel. Based on my understanding off checksum offloading, I believe that whether it is enabled or not, it should always generate the correct checksum. If there was no buggy behavior in the kernel, we would have the same results in wireshark. The fact that it generates different results for enabled vs disabled implies that there is a bug in the kernel that causes incorrect checksums, depending on the tx offload state.

[ybaruss (yabruss)]

Hello,

I put bug status to Invalid because I don't understand what is the problem:
What I know is:
> TCP or UDP frames travelling via the Internet can include some bit corruption when reaching a its destination.
> To manage that issue, those frames include checksum that allow to know if each frame is corrupted or not but it needs a quite heavy computation.
> Some Ethernet device include that check on its hardware but others no. Also wireshark will redo it for you.

Correct me if I am wrong but when Alejandro reports that he cannot configure "ethtool -k eth0" it may be because its device do not support it. Note that the tx-checksumming is not really relevant because checksum control is only useful for rx frames to know if they are corrupted. Note also the wireshark will check it only on rx. Thus statistics that you obtain shows that 90% of received frames are correct ... you Internet connection is "not too bad".

Also, as you can see there: http://en.wikipedia.org/wiki/TCP_Offload_Engine there are reasons why Linux architecture do not support sub-contracting IP frame whole management to hardware.

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.