Bug 79493 - (dhcp-dup-hostnames) DHCP server provides clients with wrong hostnames
DHCP server provides clients with wrong hostnames
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: dhcp (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-12 07:12 EST by Steffen Grunewald
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-07 11:16:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Steffen Grunewald 2002-12-12 07:12:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; OSF1 V4.0 alpha)

Description of problem:
We're running a cluster of ~150 machines here. They get both IP addresses and
host
names from two servers, one set up for odd IPs, the other for even ones.
All machines get their IP address fine, but when ifup is run for eth0 and dhcpcd
is started
(with options -n -H eth0), the hosts get random host names.
A way to avoid this is to have a delay of 3--5 seconds between the starts.
Removing -H results in all hosts being named "localhost".


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


How reproducible:
Always

Steps to Reproduce:
1. Shut down all DHCP clients (slave nodes of the cluster).
2. wake-on-lan them without delays.
3. run hostname on each node
	

Actual Results:  Nodes get the right IP address, but a random name. Names may
occur several times.

Expected Results:  Since there is an 'option host-name "xxx"' for each host
entry in dhcpd.conf, I'd expect
the client to get this information. dhcpcd runs with -n -H eth0

Additional info:

The relevant snippet from dhcpd.conf:


        host n002 {
                hardware ethernet 00:02:B3:B6:48:01;
                fixed-address 192.168.100.002;
                option host-name "n002";
        }

        host n004 {
                hardware ethernet 00:02:B3:B8:29:80;
                fixed-address 192.168.100.004;
                option host-name "n004";
        }
Comment 1 Steffen Grunewald 2002-12-13 04:25:33 EST
Using tcpdump and dhcpdump, we found out that the bug is not caused by dhcpd,
but dhcpcd on different nodes sends out requests with the same XID so replies
from the server(s) get misinterpreted.
This has been fixed in a later version of dhcpcd (1.3.22pl2).
The site www.phystech.com/download/ already has 1.3.22pl3 ready for d/l.

Please upgrade the package from 1.3.18pl8 to at least 1.3.22pl2.

I attach a snippet from 
http://www.phystech.com/download/dhcpcd_changelog.html:

09/21/02 - v.1.3.22-pl2
	...
        Michal Dobes <dobes@tesnet.cz> pointed out there could be situation with
        many dhcpcd clients starting at the same time on different machines on
the
        same network in which case they will generate the DHCP messages with the
        same XID and potentially configure the same IP addresses. Fixed by
        including CLientHwAddr (MAC address) into the seed for srandom(). -S.V.
	...
Comment 2 Daniel Walsh 2002-12-13 06:33:14 EST
I have just taken over support of dhcp in RedHat, but my investigation shows that
we have switched to using isc version of dhcp in 8.0.  dhcp-3.0pl1-9 from
www.isc.org.   Have you tried this version?  If so does it fix your problem?

Dan 
Comment 3 Steffen Grunewald 2002-12-13 08:08:47 EST
Hi Dan,

looking at the tcpdumps, it seems not to be dhcp's fault (but there's no
way to select more than one package in the bug report). I already changed
the package to dhcpcd. Please look at www.phystech.com

Steffen

Bug reassigned. (to whoever is responsible for dhcpcd)
Comment 4 Daniel Walsh 2002-12-13 09:10:51 EST
I am responsible for both.dhcp-3.0pl1-9 has both the client and server code in it.  
Red Hat moved away from the other distribution because they had a lot of
problems with it, so I am told.

Please try dhcp-3.0pl1 as the server and tell me if this solves the problem.

Dan
Comment 5 Elliot Lee 2002-12-13 09:18:34 EST
So I'll set the component as dhcp again.

Note that this bug report is against 7.2, which did use dhcpcd still.

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