Wrong UDP Packets Checksum

[Steven]

Binary package hint: linux-source-2.6.20

UDP packets checksum is wrong with my card:

steven@steven-desktop:~$ lspci | grep Marvell
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 15)

I discovered this bug trying to set up a DHCP server for my LAN, UDP packets got dropped by the client because their checksum was wrong.

This is due to checksum offloading, if i disable it using:
sudo ethtool -K eth0 rx on tx off

everything works, if I re-enable it on tx then i'm unable to get an IP.
This only seems to affet UDP packets, for tcp packet everything works fine.

This is a similar bug:

https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/31273

it is normal that packets get captured with wrong checksum, cause the checksum will be added by the card, however some cards (like mine) send a wrong checksum on wire.

Driver:
steven@steven-desktop:~$ sudo ethtool -i eth0
driver: sky2
version: 1.13
firmware-version: N/A
bus-info: 0000:02:00.0

Output of ethtool -k:
steven@steven-desktop:~$ sudo ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off

(Notice "Cannot get device udp ....")

steven@steven-desktop:~$ uname -a
Linux steven-desktop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

(Credit to dnsmasq team for help)

[Sunny Shin (shin-seu)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducable with the live environment of the Desktop CD of the development release - Gutsy Gibbon. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed kernel. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Steven (steven3000)]

Same problem on Gutsy Gibbon Tribe 3 from LiveCD

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686 GNU/Linux

Thanks

[Steven (steven3000)]

The same problem also affects this card (similar to mine):

angelica@angelica-desktop:~$ lspci | grep Marvell
02:15.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)

angelica@angelica-desktop:~$ sudo ethtool -i eth0
Password:
driver: skge
version: 1.9
firmware-version: N/A
bus-info: 0000:02:15.0

This was tested only on Feisty Fawn since I don't have my laptop here right now to sniff packets, if you want I can arrange to test with Gutsy Gibbon also.

angelica@angelica-desktop:~$ uname -a
Linux angelica-desktop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Thanks again.

[Sunny Shin (shin-seu)]

For kernel team, could you please add the output of 'dmesg' and 'lspci -vvn' as multiple seperate txt files.
Thank you for your time.

[Steven (steven3000)]

Here you are :)

HTH

(Should I change the status to new?!)

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[[e-mail] (prower2000-gmail)]

The new 2.6.27 kernel does not solve this problem for me, all UDP packets sent out by my machine now contain incorrect checksums (which has made playing most online games in Intrepid impossible). Please keep this bug open and try to find a way to the bottom of it.

I will attach my hardware information as well...please look into this if possible, it's a severe problem.

[[e-mail] (prower2000-gmail)]

Here also is the output of lspci -vv for my machine:

[[e-mail] (prower2000-gmail)]

weighing in on this issue again, i have observed the traffic coming from my network card (e1000e chipset on an ICH8-based motherboard) and there is all kinds of erratic behaviour...for example:

while visiting web-pages and sniffing traffic with wireshark, random "ethernet" packets with random MAC addresses can be observed being transmitted and received...the contents of these malformed ethernet packets contain anything from bits of the html itself, to fragments of images, etc.

i understood that the e1000e "corruption" bug was already fixed but this seems not to be the case, somehow the packets themselves are being malformed...just to make sure i replaced my card with an old realtek pci and all networking issues immediately vanished, no malformed packets recorded by wireshark or ettercap

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Thomas Novin (thomasn80)]

I can see this issue on Ubuntu Jaunty alpha 6.

From lspci -vv:

10:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)
 Subsystem: Hewlett-Packard Company Device 0934
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at c8000000 (64-bit, non-prefetchable) [size=64K]
 Expansion ROM at <ignored> [disabled]
 Capabilities: <access denied>
 Kernel driver in use: tg3
 Kernel modules: tg3

thnov@thomas-laptop:~$ uname -r
2.6.28-8-generic
thnov@thomas-laptop:~$ lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

[Thomas Novin (thomasn80)]

In a secured network this leads to a dropped DHCP request which is critical, the client cannot get a lease.

For example, with 'ip arp inspection validate' in Alcatel OmniSwitch the switch will report this when having checksum offloading enabled:

SRC MAC 00:15:60:ae:d0:65 SRC IP 192.168.100.105 DST MAC 00:00:00:00:00:00 DST IP 192.168.100.1
01-Jan-2000 04:29:05 %ARPINSP-I-PCKTLOG: ARP packet dropped from port e2 with VLAN tag 152 and reason: packet verification failed
SRC MAC 00:15:60:ae:d0:65 SRC IP 192.168.100.105 DST MAC 00:00:00:00:00:00 DST IP 192.168.100.1

[Jeff Singer (jeffasinger)]

I think this is probably related:
I'm currently using Ubuntu 9.04, with kernel 2.6.28-11-generic #42-Ubuntu SMP x86-64.
Some programs have problems with UDP checksums, and others don't. When analyzing traffic with wireshark, all of the packets sent from any of the affected programs show up as having a bad checksum, no matter
2 programs that I've noticed specifically that have this problem is a java application that uses java.net to send udp packets, and netcat. For these programs it happens no matter which interface I send the packet out on (ath0, eth0, or loopback). However, if I unplug my network card, everything works as expected.

I'm having absolutely no problem using other udp programs (DNS, etc work fine). netcat works fine in tcp, but not udp. sendip works for udp, but I think it is possible sendip computes the checksums itself.

Relavent line from lspci:
00:19.0 Ethernet controller: Intel Corporation 82566MC Gigabit Network Connection (rev 03)

[Jim Lieb (lieb)]

This bug report drifts between different vintage kernels and widely different NICs. In one of the dmesg logs, TSO is in fact turned off. If you are currently experiencing this problem, Please test and confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop . If the issue remains in Jaunty, please test the latest upstream kernel build - https://wiki.ubuntu.com/KernelMainlineBuilds . Let us know your results. the results we are interested in are the kernel version, type of NIC, a status of the NIC showing the TSO status, and a summary of the test along with wireshark traces showing the errors. Thanks.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

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