DHCP client protocol timing affected by NTP time change

[ksladic]

Hi.

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.

I have set a short lease time and noted, that from that point on, there is no renew
requests initiated by the client.

So, I wonder, is it possible that instead of after 15 seconds the client will try to

renew in 12 hours and 15 seconds since the time has been set 12 hours in the

past?

Example (timeout calculation is just as an example):

1. bootup, system time Aug 8 02:00:00pm

2. start DHCP client acquire IP at Aug 8 02:01:00pm
    calculated renew on Aug 8 02:01:15pm

3. NTP at 02:01:05PM sets system time to Aug 8 02:01:05AM

4. DHCP client waits nearly 12 hours until system time is Aug 8 02:01:15pm again

I will look at the source code, but just like to ask if someone knows if this is

how it should behave or maybe I am missing something (configuration etc.).

Thank you very much in advance.

RegK

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Eugene Grosbein]

08.08.2017 8:37, Klemen Sladic wrote:
> Hi.
>
> 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.

The only case it could happen that's client keeping local time in its RTC
instead of UTC time. Fix it to keep UTC time in the RTC and it will be fine.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Pavel Zhukov]

Eugene Grosbein <[hidden email]> writes:

> 08.08.2017 8:37, Klemen Sladic wrote:
>> Hi.
>>
>> 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. dhcp code
widely uses gettimeofday() and it's well known issue. Besides of that
there are systems without RTC at all (and OS can have lifetime per
interface and end up without IP address at all).

For example:
https://bugzilla.redhat.com/show_bug.cgi?id=916116
https://bugzilla.redhat.com/show_bug.cgi?id=1093803



>
> The only case it could happen that's client keeping local time in its RTC
> instead of UTC time. Fix it to keep UTC time in the RTC and it will be fine.
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Eugene Grosbein]

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.


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mike-2]

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.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Tue, Aug 8, 2017 at 9:48 AM, Mike <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Tue, Aug 8, 2017 at 9:52 AM, Bob Harold <[hidden email]> wrote:

On Tue, Aug 8, 2017 at 9:48 AM, Mike <[hidden email]> 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

If the clock change is because of dual-booting Windows (which sets the hardware clock to local time) and Linux (which sets the hardware clock to UTC), then there are solutions to make both operating systems set the hardware clock the same way.  Search for "linux windows dual boot system clock"

-- 

Bob Harold

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[ksladic]

Hi.

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.

RegK

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

On Tue, Aug 8, 2017 at 9:48 AM, Mike <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users