Bug 498658 - dhclient makes system unresponsive with very short leases
dhclient makes system unresponsive with very short leases
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Alexander Todorov
Depends On:
  Show dependency treegraph
Reported: 2009-05-01 13:50 EDT by Simon Matter
Modified: 2010-03-30 04:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 04:18:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Use 60 seconds as minimum for a lease (579 bytes, patch)
2009-05-01 13:50 EDT, Simon Matter
no flags Details | Diff
RPM package patch I use for myself (2.50 KB, patch)
2009-05-01 13:53 EDT, Simon Matter
no flags Details | Diff

  None (edit)
Description Simon Matter 2009-05-01 13:50:28 EDT
Created attachment 342132 [details]
Use 60 seconds as minimum for a lease

Description of problem:
When a system running dhclient gets a very short lease, it goes completely crazy and it looks like kind of a DOS.

Version-Release number of selected component (if applicable):
Note: all ISC dhcp versions seem affected, I have checked dhcp-4.1.1b1 and it seems to do exactly the same.

How reproducible:

Steps to Reproduce:
1. Configure a dhcp server with 'dhcp-lease-time 2'
2. Start 'dhclient' on a client
Actual results:
The client tries to renew it's lease in a loop as fast as it can. The network connection becomes almost unusable and the system becomes almost unresponsive. Of course dhclient floods the clients log and may quickly fill the /var filesystem. The system spends much time running dhclient-script for every request. The whole thing looks like a DOS.
As a side effect the same log flooding happens on the server - but he gets what he deserves.

Expected results:
dhclient should add a sanity check to make sure it doesn't bring the system down when getting short leases. The OpenBSD and other BSD folks have done so and they seems to live well with it: http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/dhclient.c.diff?r1=1.57;r2=1.58;f=h

Additional info:
AFAIK DHCP doesn't define a minimum lease time. However, it's not good that a badly configured DHCP server can melt down it's clients so easy. I have seen this kind of 2 second leases on mobile broadband networks (GPRS/UMTS/HDSPA). I usually get leases of about 300 seconds but from time to time it is reduced to 2 seconds for whatever reason.
If, in a large corporat network, someone is able to run it's own DHCP server and configures 'dhcp-lease-time 2' on it, he may be able to make a lot of machines unusable very quickly. It just looks too easy to me.
Attached patch derived from OpenBSD uses a minimum of 60 seconds for it's lease which means it starts renewing it every ~27 seconds.
Comment 1 Simon Matter 2009-05-01 13:53:45 EDT
Created attachment 342134 [details]
RPM package patch I use for myself
Comment 2 Alexander Todorov 2010-01-26 08:49:13 EST
what's the minimum max-lease-time value below which we'd like the client application to update it's lease every 30 seconds or so? I.e. if max-lease-time==10 how often should the client update?
Comment 3 Jiri Popelka 2010-01-26 08:59:05 EST
I agree with minimum lease time set to 60 seconds.
When the server is configured with max-lease-time less then 60 seconds, client
uses 60 seconds for his lease time, which means it starts renewing it every ~27
Comment 5 RHEL Product and Program Management 2010-01-26 10:12:15 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 7 Alexander Todorov 2010-02-23 13:22:14 EST
Tested with dhclient-3.0.5-23.el5 and a server configured with max-lease-time 2. 
The client is renewing its address every 30 seconds or so which matches the described behavior above. 

Just FYI the client in RHEL 5.4 was renewing the leases every 0-1 seconds. 

Moving to VERIFIED.
Comment 9 errata-xmlrpc 2010-03-30 04:18:52 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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