Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org

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


Today's Topics:

   1. DHCPv6 CLI dump utility (Miloslav H?la)
   2. Re: DHCP client protocol timing affected by NTP time change
      (Pavel Zhukov)
   3. Re: DHCP client protocol timing affected by NTP time change
      (Eugene Grosbein)
   4. Re: DHCP client protocol timing affected by NTP time change (Mike)
   5. Re: DHCP client protocol timing affected by NTP time change
      (Bob Harold)
   6. Re: DHCP client protocol timing affected by NTP time change
      (Bob Harold)


----------------------------------------------------------------------

Message: 1
Date: Tue, 8 Aug 2017 14:19:07 +0200
From: Miloslav H?la <miloslav.h...@gmail.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: DHCPv6 CLI dump utility
Message-ID: <8d0a464d-b56b-0f47-4470-89e21fce8...@gmail.com>
Content-Type: text/plain; charset=iso-8859-2; format=flowed

Hi all,

in case you need a DHCPv6 packets dumper CLI utility, I wrote one [1].

It requires PHP 7+ (already in Debian Stretch). Chosen language may look 
inappropriate. Originally I wanted to write prototype as soon as 
posible, but I stay with it finally.

Kind regards, Milo


[1] https://github.com/milo/dhcp6dump


------------------------------

Message: 2
Date: Tue, 08 Aug 2017 14:29:46 +0200
From: Pavel Zhukov <pzhu...@redhat.com>
To: Eugene Grosbein <eu...@grosbein.net>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP client protocol timing affected by NTP time change
Message-ID: <87efsm2qf9....@pzhukov-workstation.usersys.redhat.com>
Content-Type: text/plain

Eugene Grosbein <eu...@grosbein.net> 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
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

Message: 3
Date: Tue, 8 Aug 2017 19:39:09 +0700
From: Eugene Grosbein <eu...@grosbein.net>
To: Pavel Zhukov <pzhu...@redhat.com>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP client protocol timing affected by NTP time change
Message-ID: <5989b0ed.30...@grosbein.net>
Content-Type: text/plain; charset=windows-1251

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.




------------------------------

Message: 4
Date: Tue, 8 Aug 2017 09:48:39 -0400
From: Mike <the.li...@mgm51.com>
To: dhcp-users@lists.isc.org
Subject: Re: DHCP client protocol timing affected by NTP time change
Message-ID: <32948ef3-cf30-45ce-9b22-c9e1b4ea0...@mgm51.com>
Content-Type: text/plain; charset=utf-8

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.


------------------------------

Message: 5
Date: Tue, 8 Aug 2017 09:52:38 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP client protocol timing affected by NTP time change
Message-ID:
        <CA+nkc8DJjpAOfV7xeQ5sFPyfRpc0DAV+Rz=9zrknp2gqgwt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Tue, Aug 8, 2017 at 9:48 AM, Mike <the.li...@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-0001.html>

------------------------------

Message: 6
Date: Tue, 8 Aug 2017 09:57:28 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP client protocol timing affected by NTP time change
Message-ID:
        <CA+nkc8C=qJtbqC9pqZrisV7aDi7cqLKtQKw=Wx=ycgmyxhh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Tue, Aug 8, 2017 at 9:52 AM, Bob Harold <rharo...@umich.edu> wrote:

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

------------------------------

Subject: Digest Footer

_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

------------------------------

End of dhcp-users Digest, Vol 106, Issue 6
******************************************

Reply via email to