dhcpcd-discuss

Hi Roy,
finally I worked on this topic and I discovered that systemd-timesyncd
already has fallback servers.
It's not working exactly as fallback as I thought, but better than nothing.
To do that I have to reload systemd configuration, because there is no way
to do it dynamically at runtime.
I also upgraded to the latest dhcpcd 9.x.x and it's working perfectly.

I have 3 questions:

1) Which dhcpcd events should I listen to in my hook file?
Because in my dhcpcd hook, I trigger the update of systemd configuration
passing new_ntp_servers when $if_up is true, but for sure I have to listen
for other changes, in particular about $reason values.
I suppose that I should also handle BOUND, RENEW, REBIND and REBOOT reasons.
Do you have suggestions about this?

2) Based on your experience, do you know which router is able to set a
custom NTP server and send it via DHCP? Because, It's very difficult to
work on this without being able to try it in a real network. I found Cisco
routers, but I prefer to find something cheaper like a domestic/home
router, because I need it only to test my configuration.

3) Which is the best way to log DHCP packets on my device with dhcpcd to
understand if it's really receiving an NTP via DHCP?

Thanks,
Stefano


Il giorno gio 23 gen 2020 alle ore 01:05 Stefano Cappa <
stefano.cappa.ks89@xxxxxxxxx> ha scritto:

> Thank u all to both Roy and Neal for the very detailed explanation about
> this topic. Really appreciated.
>
> Stefano
>
> Il mer 22 gen 2020, 01:15 Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx> ha
> scritto:
>
>> On Tue, 21 Jan 2020 22:49:26 +0000
>> Roy Marples <roy@xxxxxxxxxxxx> wrote:
>>
>> >       Hi
>> >
>> > On 21/01/2020 09:23, Stefano Cappa wrote:
>> > > Hi Roy,
>> > > I'm not an expert about this topic and I have a question about NTP
>> via DHCP as
>> > > described in RFC 2132.
>> > > Basically, my device with dhcpcd 8.1.x (or later when released) must
>> use a NTP
>> > > server via DHCP if provided, otherwise it must use an external server
>> as a fallback.
>> > > This behaviour is an external requirement and I have to check if it's
>> currently
>> > > working in this way, but I really don't know how.
>> > >
>> > > How can I check if this behaviour is right? How can I specify a
>> working NTP
>> > > server via dhcpcd and check if it will have higher priority than
>> external servers.
>> > >
>> > > I'm sorry for the bad explanation, but I don't have other
>> information, because
>> > > for me this topic is totally new.
>> >
>> > OK
>> >
>> > All dhcpcd does is take a DHCP message, parse it's options and pass
>> that to the
>> > hooks.
>> > dhcpcd supplies a NTP hook which adds any NTP server given to the
>> system
>> > ntp.conf file. If a following message no longer supplies this then it
>> is removed.
>> >
>> > NTP decides the *best* server itself by measuring data from NTP servers
>> in the
>> > config.
>> >
>> > You might be able to achieve what you want by supplying no NTP servers
>> in the
>> > default ntp.conf and in /etc/dhcpcd.enter-hook set the variable
>> new_ntp_servers
>> > if it's not already set - something like this
>> >
>> > # Default NTP servers if non supplied
>> > # This ensures that if DHCP supplies some, only they are used
>> > if [ -z "$new_ntp_servers" ]; then
>> >       new_ntp_servers="192.168.0.1 10.0.0.1"
>> > fi
>> >
>> > But this means the servers can't be used as a fallback if the ones
>> given by NTP
>> > don't work. If that's critical then you have to convince NTP in
>> ntp.conf, which
>> > is outside the scope of dhcpcd.
>>
>> To expand on this, a bit of history is needed. This is outside this
>> list's purpose, but may help Stefano to better understand NTP in general.
>>
>> In the 'early' days of NTP, the daemon would get the time from some
>> upstream server and set its system clock to it. It might even check that
>> server from time to time and adjust the local clock as needed. But
>> eventually it was determined that this wasn't good enough, largely for two
>> reasons. One reason was that this operation could cause large jumps in the
>> local clock, including backward jumps; such erratic clock behavior could
>> cause undesired system operations. Another reason is that nearly all system
>> oscillator chips are either slow or fast; slow chips could result in
>> significant forward jumps in time, and fast chips could cause significant
>> backward jumps in time. So Linux was changed to allow the system to control
>> 'ticks per second' in order to better synchronize the system clock with
>> 'real' time. And ntpd operation was changed to make it happen.
>>
>> Today's NTP daemons rely on several upstream servers to find and use the
>> 'best' reference. They will then either slow down or speed up the clock so
>> that it will eventually align with the chosen upstream server. Once the
>> system clock is synchronized, the daemon periodically check to ensure the
>> clock has remained synched. The result is that the system clock is usually
>> around 12 microseconds of correctly following the passage of time and
>> having the correct time, and there are no large jumps in time. For most
>> Linux systems, 12µs is close enough. The clock rate adjustments (faster or
>> slower) are usually down around 50ppb (parts per billion, or 50
>> nanoseconds).
>>
>> When I finally understood this, I modified Smoothwall Express to (1) hard
>> set the system clock early during bootup, (2) to run the NTP daemon using
>> four upstream server: {0,1,2,3}.pool.ntp.org; their DNS server chooses
>> these servers to be near (on a planetary internet scale) the system using
>> them, and (3) to allow the admin to specify a local server if the location
>> has one for the facility (the assumption being that the local NTP server
>> will be more, mmm, consistent than external servers). Almost immediately,
>> internal system clocks became much more stable and consistent.
>>
>> Returning to Stefano's problem, he could use the server provided via DHCP
>> in addition to at least four external servers. (It's akin to the GPS system
>> where the more satellites you see, the more accurate your position report
>> will be.) As to verification, Stefano should be able to
>>   grep -i ntp /var/log/messages
>> to see which servers are valid or invalid, and how much the clock rate is
>> adjusted. (But check the syslog config; NTP logs might be directed
>> somewhere else.)
>>
>> I would suggest hard-configuring the local server and four pool servers
>> rather than relying on DHCP. Neither daemon (openntpd or ntpd) seems to
>> have an easy way to change the configured servers without restarting the
>> daemon, and restarting means going through the synchronization process
>> again which can take more than several minutes (up to 20 minutes, IIRC).
>> The daemons are usually fairly smart in handling communications with
>> upstream servers.
>>
>> In short, use not fewer than four servers all the time; the daemon will
>> determine the best one to use. The system will have a clock that is stable
>> to around 50µs which is good enough for most Linux purposes.
>>
>> N
>>
>