Overflow in lease time and potentially in renew/rebind of IPv6 client
name: Lease time calculations overflow in IPv6 client. about: dhclient v6
Describe the bug
For large values of life time for IPv6 leases, e.g.
default-lease-time 4294967294 # or -2, dhclient calculations in
client/dhc6.c cause overflow in systems using a 32 bit signed integer for the TIME data type. As a result dhclient enters an infinite loop since a negative relative expiration time is considered immediately expired.
To Reproduce Steps to reproduce the behavior:
- Run dhcp server IPv6 with a config containing the following:
default-lease-time 4294967294; # or -2 option dhcp-renewal-time 3600; option dhcp-rebinding-time 7200;
- A client solicits a new lease by broadcasting a SOLICIT packet. The above server sends then an ADVERTISE, following by the client sending a REQUEST, and finally the server sending a REPLY.
- The client then immediately repeats sending a SOLICIT packet.
- This cycle goes on forever.
Expected behavior After receiving the REPLY packet the client should not repeat sending a SOLICIT packet.
- OS: Embedded Linux (MIPS64n32 architecture)
Additional Information An example config for IPv6 dhcp server is the following: dhcpd6-example.conf
In the logs I'm seeing the following line:
PRC: Renewal event scheduled in 3600 seconds, to run for 3600 seconds. PRC: Depreference scheduled in 7200 seconds. PRC: Expiration scheduled in -2 seconds.
Some initial questions
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
I've tested it with the latest ESV version of dhclient.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time to consider migration?
It's a client issue, therefore migrating to Kea doesn't seem to provide solution to this problem.
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
Describe the solution you'd like I'm attaching a patch that seems to solve this issue:dhclient.patch
Context Seems to happen when the TIME data type used for lifetime and renew/rebind time calculations is a 32 bit signed integer type.
Participating in development
Yes, I am willing to participate in the development.
Contacting you contact email: firstname.lastname@example.org