Bug 116110 - UDP Broadcast Checksum Error
Summary: UDP Broadcast Checksum Error
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
Reported: 2004-02-18 11:25 UTC by Paul Black
Modified: 2014-10-10 04:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-19 14:23:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Captured DHCP DISCOVER broadcast with bad UDP checksum (1.61 KB, application/octet-stream)
2004-02-18 20:49 UTC, Steve Bonneville
no flags Details
Second DHCP DISCOVER broadcast with bad checksum (1.61 KB, text/plain)
2004-02-18 22:43 UTC, Steve Bonneville
no flags Details

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

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run findsmb

Actual Results:  No responses received.

Expected Results:  Should get responses from SMB/Windows machines on

Additional info:

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)
    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)
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 ...

Note You need to log in before you can comment on or make changes to this bug.