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 machines. Version-Release number of selected component (if applicable): kernel-smp-2.6.1-1.65 How reproducible: Always Steps to Reproduce: 1. Run findsmb 2. 3. Actual Results: No responses received. Expected Results: Should get responses from SMB/Windows machines on network. Additional info: Portion of dump from ethereal: User Datagram Protocol, Src Port: 32812 (32812), Dst Port: netbios-ns (137) Source port: 32812 (32812) Destination port: netbios-ns (137) Length: 58 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) and 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 ...