Bug 116110

Summary: UDP Broadcast Checksum Error
Product: [Fedora] Fedora Reporter: Paul Black <paul.0000.black>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: lxin
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-02-19 14:23:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 114961    
Attachments:
Description Flags
Captured DHCP DISCOVER broadcast with bad UDP checksum
none
Second DHCP DISCOVER broadcast with bad checksum none

Description Paul Black 2004-02-18 11:25:00 UTC
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)

Comment 1 Steve Bonneville 2004-02-18 20:33:16 UTC
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.

Comment 2 Steve Bonneville 2004-02-18 20:49:47 UTC
Created attachment 97810 [details]
Captured DHCP DISCOVER broadcast with bad UDP checksum

Comment 3 Steve Bonneville 2004-02-18 22:43:08 UTC
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).

Comment 4 Dave Jones 2004-02-19 11:47:21 UTC
should be fixed in 2.6.3-1.91


Comment 5 Paul Black 2004-02-19 13:42:23 UTC
2.6.3-1.91 works for me.


Comment 6 Paul Black 2004-05-06 14:40:38 UTC
This seems to have reappeared: present in 2.6.5-1.351smp. Ethereal
shows  incorrect UDP checksum when running rup.



Comment 7 Paul Black 2004-05-06 16:07:28 UTC
Seems to be refixed in 2.6.5-1.352smp ...