Send dhcp-users mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."

Today's Topics:

   1. Re: DHCP client protocol timing affected by NTP time change
      (Klemen Sladic)


Message: 1
Date: Thu, 10 Aug 2017 10:21:51 +1200
From: Klemen Sladic <>
To: Users of ISC DHCP <>
Subject: Re: DHCP client protocol timing affected by NTP time change
Content-Type: text/plain; charset="utf-8"


Thank you all for your comments and suggestions.

I will have to spend some more time to see which solution should I apply.
For now, a temporary one is to restart the DHCP client on date/time change.
This is far from how it should be done, I think, but will fix the problem
at the moment.

I have to find out how this NTP-related stuff works on "real" systems.


On Wed, Aug 9, 2017 at 1:52 AM, Bob Harold <> wrote:

> On Tue, Aug 8, 2017 at 9:48 AM, Mike <> wrote:
>> On 8/8/2017 8:39 AM, Eugene Grosbein wrote:
>> > 08.08.2017 19:29, Pavel Zhukov wrote:
>> >
>> >>>> I am experiencing an interesting problem with DHCP client timeouts.
>> >>>> When the system boots up it set its date/time, starts DHCP client
>> and NTP client.
>> >>>> Only after the DHCP client interface is configured, the NTP client
>> is able to access
>> >>>> the NTP server.
>> >>>> In my case, when NTP client adjusts the date/time it is set 12 hours
>> back because
>> >>>> of different time zone.
>> >>>
>> >>> That's plain wrong and that's a root of your problem.
>> >>> In no way a time zone difference should affect NTP time and kernel
>> >>> time.
>> >> Unfortunately it's not. Some systems keep local time in RTC.
>> >
>> > They are asking for troubles. They should not do that.
>> > dhcp code is not only one that would misbehave due to kernel time step
>> back.
>> >
>> >> Besides of that there are systems without RTC at all
>> >
>> > Yes, and I have such system. They init kernel time with some constant
>> in the past
>> > at the boot time (like, 1 Jan 2000) and step time forward, not back.
>> > So, they don't have this problem.
>> Perhaps a workaround in the OP's instance would be to run the date
>> command early in the boot cycle (before DHCP and NTP start) and set the
>> system time to some early value.  Then, when ntp finally starts up it
>> will be a guaranteed jump forward.
> Good idea.  As an alternative, add a "dhcp renew" after ntp updates the
> time.  I think that might be safer.  Would that work?
> --
> Bob Harold
> _______________________________________________
> dhcp-users mailing list
-------------- next part --------------
An HTML attachment was scrubbed...


Subject: Digest Footer

dhcp-users mailing list


End of dhcp-users Digest, Vol 106, Issue 8

Reply via email to