Bug 79493 (dhcp-dup-hostnames)

Summary: DHCP server provides clients with wrong hostnames
Product: [Retired] Red Hat Linux Reporter: Steffen Grunewald <steffen.grunewald>
Component: dhcpAssignee: Daniel Walsh <dwalsh>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2CC: ballen
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-07 16:16:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Steffen Grunewald 2002-12-12 12:12:31 UTC
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
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:

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;
                option host-name "n002";

        host n004 {
                hardware ethernet 00:02:B3:B8:29:80;
                option host-name "n004";

Comment 1 Steffen Grunewald 2002-12-13 09:25:33 UTC
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 

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
        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 11:33:14 UTC
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?


Comment 3 Steffen Grunewald 2002-12-13 13:08:47 UTC
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


Bug reassigned. (to whoever is responsible for dhcpcd)

Comment 4 Daniel Walsh 2002-12-13 14:10:51 UTC
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.


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

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