When testing bug 662254 I realised there is a similar problem in the server side of ISC DHCP. 662254 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Prepare a clean client and a clean server client# rm /var/lib/dhclient/dhclient.leases server# rm /var/lib/dhcpd/dhcpd.leases server# touch /var/lib/dhcpd/dhcpd.leases 2. Prepare server's /etc/dhcp/dhcpd.conf (make sure to use the correct subnet) option domain-name "example.org"; option domain-name-servers 8.8.8.8; default-lease-time 0xffffffff; max-lease-time 0xffffffff; subnet 192.168.25.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.25.10 192.168.25.20; option routers 192.168.25.1; } 3. Start/restart dhcp server service dhcpd restart 4. Start dhcp client from commandline dhclient eth1 5. Observe the server logs... Jul 25 21:57:40 router dhcpd: DHCPDISCOVER from 52:54:00:eb:e9:fb via eth1 Jul 25 21:57:41 router dhcpd: DHCPOFFER on 192.168.25.10 to 52:54:00:eb:e9:fb via eth1 Jul 25 21:57:41 router dhcpd: DHCPREQUEST for 192.168.25.10 (192.168.25.1) from 52:54:00:eb:e9:fb via eth1 Jul 25 21:57:41 router dhcpd: DHCPACK on 192.168.25.10 to 52:54:00:eb:e9:fb via eth1 So far so good. 6. Restart the DHCP client client# killall dhclient client# dhclient eth1 7. Observe the server logs... Jul 25 22:01:31 router dhcpd: Unable to set up timer: out of range Jul 25 22:01:31 router dhcpd: Jul 25 22:01:31 router dhcpd: This version of ISC DHCP is based on the release available Jul 25 22:01:31 router dhcpd: on ftp.isc.org. Features have been added and other changes Jul 25 22:01:31 router dhcpd: have been made to the base software release in order to make Jul 25 22:01:31 router dhcpd: it work better with this distribution. Jul 25 22:01:31 router dhcpd: Jul 25 22:01:31 router dhcpd: Please report for this software via the Red Hat Bugzilla site: Jul 25 22:01:31 router dhcpd: http://bugzilla.redhat.com Jul 25 22:01:31 router dhcpd: Jul 25 22:01:31 router dhcpd: exiting. dhcp-4.2.4-0.4.rc1.fc17.x86_64
A very simple and stupid patch seems to work around for me: Index: dhcp-4.2.4-P1/common/dispatch.c =================================================================== --- dhcp-4.2.4-P1.orig/common/dispatch.c +++ dhcp-4.2.4-P1/common/dispatch.c @@ -320,6 +320,11 @@ void add_timeout (when, where, what, ref q->next = timeouts; timeouts = q; +#define MAX 0x10000 + + if (sec >= MAX) + sec = MAX; + isc_interval_set(&interval, sec & DHCP_SEC_MAX, usec * 1000); status = isc_time_nowplusinterval(&expires, &interval); if (status != ISC_R_SUCCESS) { This is not a proper fix but it keeps DHCP server running. You can tweak the value of course. If you want to play with it, you can use a scratch build of mine before a proper fix is out: http://koji.fedoraproject.org/koji/taskinfo?taskID=4329834
Most likely a duplicate of bug #789601 (the security-flag should be removed soon). Can you test this scratch-build ? http://koji.fedoraproject.org/koji/taskinfo?taskID=4330107
I confirm DHCP server now DHCPACK's the lease and continues to run with: Jul 26 09:43:02 router dhcpd: Timeout requested too large reducing to 2^^32-10 Jul 26 09:43:02 router dhcpd: DHCPREQUEST for 192.168.25.10 from 52:54:00:eb:e9:fb (station) via eth1 Jul 26 09:43:02 router dhcpd: DHCPACK on 192.168.25.10 to 52:54:00:eb:e9:fb (station) via eth1 Next dhclient run just: Jul 26 09:44:29 router dhcpd: DHCPREQUEST for 192.168.25.10 from 52:54:00:eb:e9:fb (station) via eth1 Jul 26 09:44:29 router dhcpd: DHCPACK on 192.168.25.10 to 52:54:00:eb:e9:fb (station) via eth1 *** This bug has been marked as a duplicate of bug 789601 ***
> *** This bug has been marked as a duplicate of bug 789601 *** That bug is restricted access. Please open the bug for general access.