Bug 116110 - UDP Broadcast Checksum Error
UDP Broadcast Checksum Error
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-02-18 06:25 EST by Paul Black
Modified: 2014-10-10 00:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-19 09:23:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 15:49 EST, Steve Bonneville
no flags Details
Second DHCP DISCOVER broadcast with bad checksum (1.61 KB, text/plain)
2004-02-18 17:43 EST, Steve Bonneville
no flags Details

  None (edit)
Description Paul Black 2004-02-18 06:25:00 EST
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 15:33:16 EST
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 15:49:47 EST
Created attachment 97810 [details]
Captured DHCP DISCOVER broadcast with bad UDP checksum
Comment 3 Steve Bonneville 2004-02-18 17:43:08 EST
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 06:47:21 EST
should be fixed in 2.6.3-1.91
Comment 5 Paul Black 2004-02-19 08:42:23 EST
2.6.3-1.91 works for me.
Comment 6 Paul Black 2004-05-06 10:40:38 EDT
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 12:07:28 EDT
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.