ethereal and tcpdump show a lot of packets with incorrect checksum

[Laurent Bigonville]

Hi,

When I run ethreal or tcpdump on my dapper ppc, they show a lot of packets (tcp and udp) that have an incorect checksum. For example every udp packet broadcasted by cups are marked as incorect but on an other machine (with breezy x86) the checksum is marked as correct. I suppose it's a probleme with libpcap.

[Laurent Bigonville (bigon)]

The same packets captured on dapper and on breezy

[Jörg Höhle (joerg-cyril-hoehle)]

Me too. In Dapper, Ethereal says *all* outgoing TCP/UDP packets have a wrong checksum, except for TCP ACK or SYN packets. I sampled DNS(UDP), HTTP and SMB(TCP).
In Breezy, there was no such problem.
Dapper's Ethereal says that the data captured in Breezy is fine.
This happens independently of promiscuous mode.

lspci reports:
0000:01:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:01:0d.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)

/var/log contains:
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt 0000:01:0c.0[A] -> Link [LNKE] -> GSI 11 (level, low) -> IRQ 11
eth0: RealTek RTL8139 at 0xf8dfc000, 00:0b:5d:xx:xx:xx, IRQ 11
8139cp: 10/100 PCI Ethernet
8139cp: pci dev 0000:01:0c.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp: Try the "8139too" driver instead.
8139too Fast Ethernet driver 0.9.27
**** SET: Misaligned resource pointer: f7f176c2 Type 07 Len 0
eth0: RealTek RTL8139 at 0xf8c24000, 00:0b:5d:xx:xx:xx, IRQ 11

[Jörg Höhle (joerg-cyril-hoehle)]

Well, I came across
http://www.ethereal.com/faq.html#q11.1
but that only covers TCP. It's no solution to incorrect outgoing UDP (e.g. DNS) checksums.

[Bill Zaumen (zaumen)]

I've seen the same problem and can reproduce it. It
occurs when UDP packets are transmittted. I used
tcpdump's -X option to analyze the packets and
all fields are correct except for the UDP checksum.
In one test, I sent a single UDP packet between two
machines and found that only the checksum differed
(being wrong in the trace on the transmitting machine).

While the problem may be in tcpdump or a library it
uses, it could also be a kernel bug that results in a
incorrect copy of the packet being sent to tcpdump:
I verified that all the fields in a transmitted packet are
correct except for the UDP checksum - I compared
ithe traces for the transmitted packet versus the
received packet.

I've enclosed the software I used in the attachment:
a couple of very short programs (I'm running ubuntu
dapper).

[Steven (steven3000)]

I can confirm this bug.

I was trying to set up a DHCP server on Ubuntu Feisty Fawn and I notice that no responses were received from clients (also running Ubuntu), so I uses wireshark to capture packets and seems that UDP Checksum are incorrect, so offers get dropped.

I sent a message to dnsmasq mailing list and the answer was:

"The explanation for dhclient ignoring the DHCPOFFERS seems to be that
the UDP checksum is incorrect. Is the Ubuntu system the client, or the
server? The checksum problem seems to be originating on the server, and
if the server is running Ubuntu (or any Linux distro) then it's a kernel
problem: on Linux dnsmasq delegates UDP and IP header creation to the
kernel. [CUT]"

Link to the message: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q3/001501.html
Reply: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q3/001502.html

Look at the wireshark capture file: DHCPOFFER packets have an incorrect UDP Checksum, however DHCPDISCOVER packets are ok.

Server: Linux steven-desktop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux
Client: Linux steven-laptop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Steven (steven3000)]

I solved my problem, some cards support checksum offload:

( http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftungd/tcp_checksum_offload.htm )

But sometimes it doen't compute the right checksum, Just issue the following command and try again:

sudo ethtool -K eth0 rx off tx off

Credit to <email address hidden> ( http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q3/001503.html )

[nada (zephzu)]

I found this problem on a new server I built. This system acts as a local router and DNS server, and also runs vmware-server. VMware is configured with vmnet0 as a bridge to eth1, which physically links to a 10/100Mbps switch for the local LAN.
VMware instances could communicate with the host system's IP over TCP but not UDP, so DNS queries would fail. Other systems on the physical LAN can query DNS just fine.

A tcpdump capture and subsequent wireshark analysis revealed that all UDP replies coming from the host server system included a bad UDP checksum. Even UDP replies going to other systems on the physical LAN show bad checksums, but I assume those systems ignore it. VMware Server's vmnet-bridge driver might silently drop these packets.

After turning off hardware checksum offloading (ethtool -K eth1 rx off tx off), everything worked perfectly. Wireshark revealed the reply packets from the host server include a correct UDP checksum.

Kernel/hardware details:
Ubuntu Server 7.04 x86_64 (2.6.20-16-generic)
CPU: AMD Opteron 1218 (2.6GHz dual core)
Motherboard: TYAN S2925A2NRF AM2 NVIDIA nForce Professional 3400 ATX Server Motherboard
NICs: 2x onboard 1000Mbps ports, using forcedeth network driver ("forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59.")

[Daniel T Chen (crimsun)]

This symptom is very probably due to hardware checksums being used. If you can disable it, please do so and attempt to reproduce the symptom.

[Crewsr3 (crewsr3)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!