DHCP client protocol timing affected by NTP time change

[Bob Harold]

On Tue, Aug 8, 2017 at 9:48 AM, Mike <the.lists at mgm51.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170808/034bce2c/attachment.html>