Bug 62948 - dhcp lease infinite
Summary: dhcp lease infinite
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dhcp
Version: 7.3
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
URL:
Whiteboard:
: 62949 71662 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-08 10:47 UTC by Thomas M Steenholdt
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-08-17 21:00:25 UTC
Embargoed:


Attachments (Terms of Use)
DHCP Daemon Configuration File (from the server :)) (265 bytes, text/plain)
2002-06-11 19:42 UTC, Thomas M Steenholdt
no flags Details
trace conducted from the client - using the proposed procedure (Both Server/Client are RH7.3) (4.25 KB, text/plain)
2002-06-11 19:45 UTC, Thomas M Steenholdt
no flags Details
dhcpd stats taken from the server after the trace was performed - the trace leads to this result (563 bytes, text/plain)
2002-06-11 19:47 UTC, Thomas M Steenholdt
no flags Details

Description Thomas M Steenholdt 2002-04-08 10:47:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311

Description of problem:
for some reason, using dhcp configuration results in an infinite lease on my
dhcp server(RH7.2 i586). I'm not sure whether this is a client or server
problem. default-lease-time and max-lease-time options have been set. With a
RH7.2 client this would also happen, but it seemed that setting the
DHCP_HOSTNAME in ifcfg-eth0 made the lease more correct. This does not seem to
be the case on skipjack. Windows clients result in correct leases on the server.

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


How reproducible:
Always

Steps to Reproduce:
1. Enable DHCP on an interface
2. Restart networking

	

Actual Results:  on the server, examining the /var/lib/dhcp/dhcp.leases, the new
entry for the test-client shows an end time 1 second before the start time

Expected Results:  on the server, examining the /var/lib/dhcp/dhcp.leases, the
new entry for the test-client should show an end time <default-lease-time> after
start time.

Additional info:

As noted above I'm not entirely sure where the problem lies. This could easily
be a server problem or maybe even a configuration problem - But nothing I've
tried has made it go away for good!

Comment 1 Thomas M Steenholdt 2002-04-08 11:33:43 UTC
*** Bug 62949 has been marked as a duplicate of this bug. ***

Comment 2 Barry K. Nathan 2002-04-15 11:52:09 UTC
I'm seeing this too, but it's sporadic. Sometimes my leases are 20 minutes or so
(this is the lease time on my DHCP server) and sometimes they're about 24 hours
(this is what I've configured my server to use for *BOOTP* leases!). Note that
the ISC DHCP server implementation defaults to infinite length leases for BOOTP
clients... (BTW, I'm running Slackware 8.0 on my server, which comes with ISC
dhcpd 2.1pl5.)

I never saw this with RH 7.2 or earlier, but OTOH I only enabled BOOTP support
on my DHCP server a few days back.



Comment 3 Thomas M Steenholdt 2002-04-15 12:06:34 UTC
I have "deny bootp;" in my dhcpd.conf file, but I doesn't seem to help my
problem any!

Comment 4 Elliot Lee 2002-04-15 16:25:07 UTC
Hmm, it seems to me that it would be valuable to narrow this down to a
client-side vs. server-side problem. Does anyone know whether it is possible to
make the problem go away by changing either the server or client? Has there been
any platform that does not exhibit this problem?

Comment 5 Thomas M Steenholdt 2002-04-15 17:06:06 UTC
My wife's Windows Xp client, seems to always result in a correct lease length of
<default-lease-time> on my RH7.2 DHCP server, so it seems to me, the client is
the "guilty one"

Comment 6 Thomas M Steenholdt 2002-05-08 10:44:39 UTC
Nothing has changed, in relation to this bug, in RH 7.3



Comment 7 Olivier Baudron 2002-06-11 16:48:40 UTC
Can someone attach his dhcpd.conf and the debugging infos given by tcpdump on
the client side:

# /etc/init.d/network stop
# ifconfig eth0 up
# tcpdump -n -i eth0 -s 2000 -X port 67
# dhcpcd

Please, use the latest version of dhcpcd and dhcp (or at least Redhat 7.3).
I will investigate on this. -- Thanks.

Comment 8 Thomas M Steenholdt 2002-06-11 19:42:59 UTC
Created attachment 60565 [details]
DHCP Daemon Configuration File (from the server :))

Comment 9 Thomas M Steenholdt 2002-06-11 19:45:03 UTC
Created attachment 60566 [details]
trace conducted from the client - using the proposed procedure (Both Server/Client are RH7.3)

Comment 10 Thomas M Steenholdt 2002-06-11 19:47:08 UTC
Created attachment 60567 [details]
dhcpd stats taken from the server after the trace was performed - the trace leads to this result

Comment 11 Olivier Baudron 2002-06-11 20:21:03 UTC
Thanks, got it!

This is a server problem. At first, the client asks for an infinite lease time.
The special value for this is -1. Then the server executes:

dhcp.c:752
    /* Don't let the client ask for a longer lease than
    is supported for this subnet or host. */
    if (lease_time > max_lease_time)
        lease_time = max_lease_time;

But, since lease_time==-1, lease_time is not set to the upper bound
max_lease_time. And the server bug is there. Finally, it reads:

    state -> offered_expiry = cur_time + lease_time;

which explains why the server logs give an expired lease time 1s in the past.

Can you try rawhide version (dhcp-3.0-7)? I had a quick look at it, and think
this bug should be fixed.

Note (for your wife;)): Windoze clients don't ask for an infinite lease time by
default, which is why the server works with it. But this is really a server
problem.

Comment 12 Olivier Baudron 2002-06-11 20:53:24 UTC
patch for RedHat 7.3:

--- dhcp-2.0pl5/server/dhcp.c   2000-06-30 21:04:52.000000000 +0200
+++ dhcp-2.0pl5/server/dhcp.c   2002-06-11 22:31:28.000000000 +0200
@@ -751,7 +751,8 @@
 
                        /* Don't let the client ask for a longer lease than
                           is supported for this subnet or host. */
-                       if (lease_time > max_lease_time)
+                       if ((lease_time > max_lease_time) ||
+                           (lease_time == -1))
                                lease_time = max_lease_time;
                } else
                        lease_time = default_lease_time;

Comment 13 Olivier Baudron 2002-06-11 22:48:51 UTC
Yes, this is indeed fixed in rawhide.

Comment 14 Elliot Lee 2002-06-11 23:37:00 UTC
Olivier deserves a trophy for tracking this down :)

Comment 15 Thomas M Steenholdt 2002-06-12 13:35:50 UTC
While we're at it... How is this supposed to work when a client request a lease
time > default_lease_time but < max_lease_time... If that scenario is handled in
the same wad of code descriped above, and the proposed lease length should be
ack'ed... It probably needs a few more changes - perhaps something like this...

if ((lease_time > max_lease_time) || (lease_time == -1)){
  lease_time = max_lease_time;
}
else 
if (lease_time < default_lease_time) lease_time = default_lease_time;

this would allow a lease time of 3 days to be proposed, where default_lease_time
is 2 days and max_lease_time is 5 days.

i'm sorry - i haven't had a look at the complete source code so it might be
handled elsewhere...

Comment 16 Olivier Baudron 2002-06-12 14:40:29 UTC
To Tmus: Don't worry, everything else is correct. The algorithm is:
- if the client does not request a lease time: set lease to default_lease_time
- else: bound the requested lease time with max_lease_time
If for some reasons the client requests a shorter lease time than the default
one, he receives what he wants!

To Elliot: You might consider publish an RH7.3 update for dhcp since:
- most people use official releases only
- dhcp in rawhide is a major version upgrade (2->3)
- the fix is trivial ;)

Comment 17 Thomas M Steenholdt 2002-06-13 04:30:02 UTC
Just to comfirm that 3.0-7 works fine here too!!!

Comment 18 Pekka Savola 2002-08-17 20:58:46 UTC
skipjack-beta2 -> RHL73, dhcpcd -> dhcp.

Reopening and raising severity; there really needs to be a RHBA IMO especially as dhcp2 is no longer in rawhide.

Comment 19 Pekka Savola 2002-08-17 21:00:21 UTC
*** Bug 71662 has been marked as a duplicate of this bug. ***

Comment 20 Elliot Lee 2002-08-26 10:45:49 UTC
Not going to do an erratum due to general priorities.


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