Regarding the dhcp lease time

Murali Krishna muralikrishch at
Mon May 13 15:16:46 UTC 2019


I agree to your comments that rather than the usecase this is a testcase.
The same test case is working without any issues, when the below versions
are available on server and client respectively.
version available on server and client: 4.2.1-P1

But the same testcase is not working when we have the below versions.
version on server: 4.3.6
version on client: 4.2.1-P1

Apart from that, the other clarification which i would like to get
clarified from the experts is that how the server acts to the DHCP requests
from the clients in a situation where the time stamps are completely
different. From the conf file server should acknowledge the respective
seconds of the leasetime(as mentioned in conf file) irrespective of the
timestamps. This is not happening in this scenario where server is offering
a huge lease value.

In the current scenario client requested for the respective lease for the
time duration as mentioned in the conf file.

Here is the sequence of flow it happened:
1. Client initiates DHCP Request for 3600s(1hr)
2. Server acknowledges(DHCP Ack) with lease time:(158253440s) 1831 days, 15
hours, 17 minutes, 20 seconds

How the server is calculating the lease time which is not the one defined
as per the conf file.

Thanks & Regards,

On Fri, May 10, 2019 at 9:55 PM Simon Hobson <dhcp1 at> wrote:

> Rob Janssen <rob at> wrote:
> > I have seen such postings many times on NTP lists and groups, where a
> "local team" wants to validate the operation of the NTP service and decides
> to write a testplan similar to this:
> >
> > - setup an isolated local network with a client and a server
> > ...
> > - manually change the clock of the client (or the server) by several
> years ...
> >
> > When that does not work out, they come and ask why.
> Or come here and ask why the DHCP service is "broken" !
> > Having a LAN address of 169.254.x.x is not that uncommon in such test
> environments.
> Which is still not valid for a DHCP server - common or not.
> We'll just have to wait for the OP to come back with an alternative
> narrative ;-)
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at


Thanks & Regards,
Muralikrishna CH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dhcp-users mailing list