Bug 612952 - DHCP daemon offered another address although the lease exists
DHCP daemon offered another address although the lease exists
Status: CLOSED DUPLICATE of bug 615995
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-09 07:53 EDT by Vadim Grinco
Modified: 2010-07-20 04:06 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-20 04:06:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vadim Grinco 2010-07-09 07:53:27 EDT
Description of problem:
DHCP daemon offered another address although the lease exists. In a couple of minutes it got the old lease back. Here's the log:

Jul  9 02:53:08 ns1 dhcpd: DHCPREQUEST for 10.34.34.181 from 00:0c:29:a3:73:d2 via eth0
Jul  9 02:53:08 ns1 dhcpd: DHCPACK on 10.34.34.181 to 00:0c:29:a3:73:d2 via eth0
Jul  9 10:49:33 ns1 dhcpd: DHCPREQUEST for 10.34.34.181 from 00:0c:29:a3:73:d2 via eth0
Jul  9 10:49:33 ns1 dhcpd: DHCPACK on 10.34.34.181 to 00:0c:29:a3:73:d2 via eth0
Jul  9 12:12:17 ns1 dhcpd: DHCPDISCOVER from 00:0c:29:a3:73:d2 via eth0
Jul  9 12:12:18 ns1 dhcpd: DHCPOFFER on 10.34.34.174 to 00:0c:29:a3:73:d2 via eth0
Jul  9 12:12:18 ns1 dhcpd: DHCPREQUEST for 10.34.34.174 (10.34.32.1) from 00:0c:29:a3:73:d2 via eth0
Jul  9 12:12:18 ns1 dhcpd: DHCPACK on 10.34.34.174 to 00:0c:29:a3:73:d2 via eth0
Jul  9 12:21:29 ns1 dhcpd: DHCPDISCOVER from 00:0c:29:a3:73:d2 via eth0
Jul  9 12:21:30 ns1 dhcpd: DHCPOFFER on 10.34.34.181 to 00:0c:29:a3:73:d2 via eth0
Jul  9 12:21:30 ns1 dhcpd: DHCPREQUEST for 10.34.34.181 (10.34.32.1) from 00:0c:29:a3:73:d2 via eth0
Jul  9 12:21:30 ns1 dhcpd: DHCPACK on 10.34.34.181 to 00:0c:29:a3:73:d2 via eth0

# grep 00:0c:29:a3:73:d2 -A 1 -B 5 dhcpd.leases
lease 10.34.34.174 {
  starts 5 2010/07/09 10:12:18;
  ends 6 2010/07/10 16:12:18;
  binding state active;
  next binding state free;
  hardware ethernet 00:0c:29:a3:73:d2;
}
lease 10.34.34.181 {
  starts 5 2010/07/09 10:21:30;
  ends 6 2010/07/10 16:21:30;
  binding state active;
  next binding state free;
  hardware ethernet 00:0c:29:a3:73:d2;
}

Version-Release number of selected component (if applicable):
server# rpm -q dhcp
dhcp-3.0.5-23.el5

client# rpm -q dhclient
(01:52:07 PM) adelton: dhclient-4.1.1-16.fc12.x86_64

How reproducible:
Not sure...

Expected results:
Get the same address as long as the lease exists.
Comment 1 Jiri Popelka 2010-07-13 11:27:46 EDT
I found this in changelog to 3.0.6rc1

- The server's "by client-id" and "by hardware address" hash table lists
  are now sorted according to the preference to re-allocate that lease to
  returning clients.  This should eliminate pool starvation problems
  arising when "INIT" clients were given new leases rather than presently
  active ones.

But when comparing (I don't have access to upstream's CVS)
source code of 3.0.5 and 3.0.6rc1
I see there's a huge amount of changes.
I'm not sure I can pinpoint the correct one
while I don't know how to reproduce the problem.
Comment 2 Jiri Popelka 2010-07-20 04:06:32 EDT

*** This bug has been marked as a duplicate of bug 615995 ***

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