Red Hat Bugzilla – Bug 116110
UDP Broadcast Checksum Error
Last modified: 2014-10-10 00:07:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
Description of problem:
UDP broadcast packets are sent with an incorrect checksum on some
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run findsmb
Actual Results: No responses received.
Expected Results: Should get responses from SMB/Windows machines on
Portion of dump from ethereal:
User Datagram Protocol, Src Port: 32812 (32812), Dst Port: netbios-ns
Source port: 32812 (32812)
Destination port: netbios-ns (137)
Checksum: 0x6272 (incorrect, should be 0x6792)
rup and ypbind (broadcast mode) are also affected.
Non-broadcast UDP is fine.
I have two other machines with FC2-test1 that work fine. The failing
machine has the following ethernet adapter:
0000:01:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet
Controller (rev 02)
The other machines have:
0000:02:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (LOM)
Ethernet Controller (rev 81)
0000:02:08.0 Ethernet controller: Intel Corp. 82801EB (ICH5) PRO/100
VE Ethernet Controller (rev 02)
I'm seeing a similar problem at install time. I'm doing an NFS
network install started with PXE, trying to get a DHCP address. Bad
checksums from anaconda's DHCP client. I will attach a packet capture
from Ethereal. Checksum is 0x0145, should be 0xbe43 according to the
sniffer. Intel 845 motherboard, 3c905C-TX/TX-M Tornado network card.
Pentium 4 1.6 GHz stepping 2. Hardware vendor is Gateway.
I successfully installed the system using a static IP at install time.
The creepy thing with this system is that post-install, if I clear
the client leases files and use DHCP to bring the interface up, it
works. The initial DHCP DISCOVER broadcast packet has a correct
checksum then, unlike at install time.
Created attachment 97810 [details]
Captured DHCP DISCOVER broadcast with bad UDP checksum
Created attachment 97813 [details]
Second DHCP DISCOVER broadcast with bad checksum
Aha! This bad DHCP DISCOVER packet sent from the same box has the *same* bad
checksum, 0x0145 (should be 0xc538 according to Ethereal). The only difference
between the packets is the payload's transaction ID field (002E through 0031)
and seconds elapsed field (0032 and 0033).
should be fixed in 2.6.3-1.91
2.6.3-1.91 works for me.
This seems to have reappeared: present in 2.6.5-1.351smp. Ethereal
shows incorrect UDP checksum when running rup.
Seems to be refixed in 2.6.5-1.352smp ...