The following explains how to integrate a local time server such GNATS into a local network. Some of this material was included in the first version of the post describing the construction of GNATS, but it should be separated for two reasons. First, the subject discussed here has nothing to do with GNATS in particular, it applies to any local NTP server. Second, adding a local NTP server to a LAN is a rather more complex task than described initially.

As far as I can ascertain, there are three ways of using the local NTP server.

• Modify the configuration of each device that needs to access an NTP server, specifying the IP address of the local NTP server. That was exactly what was done with the Raspberry Pi using GNATS as a time source. Let's call this a static NTP client configuration.
• Modify the configuration of each device that needs to access an NTP server so that it will query the DHCP server for the addresses of available NTP servers. Of course this is where the local NTP server's IP address would be provided to the client. In this scenario, the configuration of the DHCP server must be changed so that it knows the IP address of NTP servers and that it responds to request for that information from clients. The whole process, which could be labelled automatic NTP configuration, is thus a two-step procedure which is slightly more complex than the static configuration.
• Use a hybrid solution combining the above two methods. Spoiler alert: that will probably be the only practical solution.

Table of Contents

1. Static NTP Client Configuration
   1. systemd-timesyncd
   2. chrony
   3. ntp
   4. tasmota
2. Automatic NTP Configuration
   1. DHCP Server Configuration
      1. NTP Servers Option in OpenWRT
      2. NTP Servers Option in pfSense and OPNsense
   2. Client NTP Discovery Configuration
      1. systemd-timesyncd
      2. chrony
      3. ntp
      4. tasmota
3. Practical Considerations

Static NTP Client Configuration

The Raspberry Pi uses the systemd-timesyncd service to set the time from NTP servers. However that is far from a universal choice as the following table about some of the devices in the house makes abundantly clear.

Add to that list a phone and a number of tablets that I use that are running different versions of Android, my spouse's iMac and iPad, the 20 or more Tasmota based IoT devices and probably other things that I can't remember right now. It's all a bit of a mess.

systemd-timesyncd

This has already been covered at length in the previous post about GNATS.

Edit /etc/systemd/timesyncd.conf configuration file. It belongs to root, so upgrading privileges with sudo will be necessary unless one has opened a session as root. Modify the first or first and second entries in the [Time<] section.

As an example, here is the section on the Raspberrry Pi used for testing GNATS.

To check on the configuration file

chrony

I know very little about chrony, consequently what follows should be seen as an indication of a possible way to go about this. Let's start with a look at list of time sources defined by default.

Looking at the content of a few files gives a good indication of how to configure the time sources for this service.

So let's execute this as instructed.

The * beside edge-iad.txryan.com indicates [that it is] the source to which chronyd is currently synchronised while the x beside the IP address of the local NTP server indicates a clock which chronyd thinks is a falseticker (i.e. its time is inconsistent with a majority of other sources) (source: chronyc(1) Manual Page). Adding the prefer option (server 192.168.1.23 iburst prefer) which would make GNATS the primary time source does nothing. Probably because the service will not use a "falseticker" in preference to consistent time source. So with this configuration, the local time server is the backup, and remote servers will be used preferentially. This is not unreasonable, but it is the opposite of what I wanted to achieve when creating GNATS.

One could remove all the pooled servers in the main configuration file /etc/chrony/chrony.conf, and after a while, the chrony will use the local NTP server at the time source.

Of course there is no backup in this situation.

ntp

There seems to be a sentiment that chrony is a newer and better replacement of the venerable ntp from the Network Time Foundation. I am in no position to judge, but I did notice a close similarity between the programs. As before, will start the list of time sources defined by default.

It doesn't look as if ntp will load additional configuration files, so I added the local NTP server directly in the main configuration file

I don't know if there's a command to reload sources, so I juste restarted the ntp.service and checked that it was working properly

One has to wait a while before the service will look at the local time server.

As can be seen, the situation appears to be very similar to what was obtained in chrony. It would be necessary to eliminate the server pool to ensure that the local NTP server is used, but then there would be no back up.

tasmota

Accoring to the online documentation about the set up of NTP servers in Tasmota, up to three servers can be specified. For example, NtpServer1 0.can.pool.ntp.org would set 0.can.pool.ntp.org as the first NTP server, while NtpServer1 0 would clear the value. So the following command ensures that only the local NTP server be used.

However the documentation is clear. NTP servers are consulted in order, from server 1 to 3, stopping as soon as a time request is obtained. So it would probably be best to change only NtpServer1 and to let the other two unchanged or to specify explicitely which server to place in all three slots

Accordingly, the NTP servers of the Tasmota devices in the home ise the following.

Since the NTP server will provide a UTC time stamp and local time is more meaningful when using triggers such as the time, sunset, or sunrise, the time zone must be defined. As one would expect Tasmota does not store a time zone database, differences between UTC and local time have to be specified numerically. Luckily, there's no need to into the arcane details about specifying the correct time zone. Just go to the Tasmota Timezone Table~ and search for the best city for your local time.

In my case there are a few entries that could be used such as the one for Halifax. It's lucky that the only Halifax in the database is in nearby Nova Scotia, because there's at least another ten municipalities named Halifax elsewhere.

Combining these commands, the pertinent time values for a new Tasmota device could be fixed in a single backlog command.

However, it would be very tedious to find the IP address of the 20 plus Tasmota devices, open the Web interface of each of them and then manually enter the command in the Web console, if I wanted to change the address of an NTP server or the time zone of all the installed devices. Instead the commands can be sent to the devices by publishing MQTT messages. As far as I know, backlog is not supported in MQTT commands, so each command must be published independantly.

Suscribe to "stat/+/RESULT" to see the reply of all the Tasmota devices connected to the MQTT broker. I use my own MQTT client, lazmqttc, written in Lazarus / Free pascal to do this. Here is my tasmota.json file that I systematically use to send and receive MQTT messages from all the Tasmota devices on our home system. Of course the address of the MQTT broker would need to be adjusted.

Sorry for the self-promotion, mosquitto_pub, mosquitt_rr or any of the innumerable MQTT clients available for desktops or tablets and phones could just as easily be used.

Automatic NTP Configuration

Would it not be better if the local network provided the address of our tiny NTP server instead of having to manually configure the address of the NTP server of each device connected to the network? Indeed DHCP servers can provide NTP server addresses along with dynamically assigned IP addresses to clients. It took a little while to figure it out, but here is what needs to be done in broad strokes.

1. Ensure that the DHCP server (usually in the router) forwards the address of the local time server using option 42.
2. Ensure that all DHCP clients that need to access NTP servers request their addresses from the DHCP server. In other words, DHCP clients must be told to avail themselves of option 42.

As already said, my ISP provided "all-in-one" ONT/Ethernet switch/Wifi router/DHCP server etc. is very much a "consumer grade" device with very few user settings. In particular it does not have any NTP options. Consequently this approach may not be possible for many.

Networked devices with self-assigned IP addresses never communicate with the DHCP server. So the proposed scheme only works if network peripherals that need access to the NTP server (and DNS servers for that matter) use dynamic IP addressing. For servers that need a fixed IP address, have the DHCP server assign them their fixed address. So far all "consumer grade" routers that I have seen have that capability.

DHCP Server Configuration

Among the optional configuration parameters that can be returned by a DHCP server to its clients there is the

The NTP servers option (or option 42) is not usually included by DHCP servers by default. It needs to be enabled in the DHCP server and DHCP clients must request this information. Explaining in detail how to enable NTP Servers option (option 42) in all possible routers / DHCP servers is just not possible. Unfortunately, I have a single complete and tested example of how to perform the first step.

By the way, there are time zone options for DHCP as per RFC4833... we are not going down that rabbit hole.

DHCP Server Option 42 (NTP Servers) in OpenWRT

The firmware of a Rosewill 300M Wireless N which is a rebranded TP-Link TL-WR841ND v7 router has been LEDE 17.01.4. In other words, it is running a 2017 version of OpenWRT (formerly known as LEDE, itself formerly known as OpenWRT... it's complicated). In principle, it could be upgraded but that will not be done. The router, which is not in constant use, has been a very useful tool for testing network configurations without interfering with the working LAN. Hopefully, changes to OpenWrt will not have been so so major as to make the information in this section useless.

Enabling option 42 in the DHCP server can be done from the command line or with the LuCi graphical interface. The command-line method is the easiest to present so let's start with that.

I could not figure out the proper syntax, but that last line is just a warning so let's not worry about it now.

It is just as easy to enable DHCP option 42 using the graphical interface, but it is a bit more awkward to present here. Start by clicking on the Network menu and select Interfaces. Then click on the Edit button of the desired interface which in my case was the LAN interface.

There is not much documentation on this, basically just an example entitled DHC options. Maybe I just didn't know where to look.

NTP Servers Option in pfSense and OpnSense

Presumably the same can be done with other routers, but as already said, not with the one rented from my Internet service provider.

The Netgate documentation for pfSense has the following description on how to add the option to its DHCP server.

I could not find specific documentation for the equivalent in OPNsense. But in an issue in the forum, Udo says I've configured "Services -> DHCPv4 -> [Interface] -> NTP servers" with one IP which indicates that this is done in the Web interface much like in pfSense and OpenWRT.

In another topic in the forum, NTP on DHCP there is an explanation by guest19228 on how to add the option ntp-server 192.168.1.23 line in the DHCP service configuration file dhcpd.conf. Since both pfSense and OPNsense are based on FreeBDS, that explanation may be valid for both.

Client NTP Discovery Configuration

Enabling NTP discovery in DHCP clients is very similar to what was required to enable NTP servers option in DHCP servers. But of course, the details are different depending on the NTP service running on the client.

systemd-timesyncd

Remember that systemd-timesyncd is the NTP client in Raspbery Pi OS. Accordingly it is the configuration of the Raspberry Pi that will be examined in this section.

1. Make sure that the Raspberry Pi is a DHCP client, so remove any static IP address.
2. Remove the addition of a specific NTP server in etc/systemd/timesyncd.conf if that was done in the past
3. Ensure that the request in /etc/dhcp/dhclient.conf has ntp-servers. This is true by default. It means that the content of option 42 will be requested from the DHCP server.
4. Enable the ntp_servers option in the /etc/dhcpcd.conf file. This means that the list of NTP servers returned by the DHCP server will be used.

Here are commands that verify that all that was done correctly.

Then clear the journal files as much as possible. This is to make it easier to check what happened after the Pi is rebooted, just in case something goes wrong.

Before rebooting, I try to wipe out as many timestamps saved in the file system as possible. It's important get rid of /var/lib/systemd/timesync/clock because timesync would set the system time to its timestamp in the absence of an NTP time. I am not too sure why fake-hwclock is installed. It does pretty much what systemd-timesync does with clock only it actually writes the time in its own timestamp fake-hwclock.data.

As soon as I could log back in, I checked the date and time and it was correct.

All that looks very good. The time is correct, the router NTP server is being used by the Pi and the only way it could know to do that is because the DHCP server on the router provided the address.

Finally, here is an edited portion of the system journal showing how the system time was set.

Clearly there are many more timestamps that I thought but none of those shown in the journal are used to jump the system time forward except for the build time of systemd, the modified timestamp (mtime) of clock and the modified timestamp of fake-hwclock.data or its content I am not sure which. Having deleted the first two, the initial time, Dec 22 07:55:44 is derived from the compilation date of systemd.

chrony

As shown in the table above, Chrony is the NTP client installed in Armbian which is running on the Orange Pi PC 2 while systemd-timesyncd is not installed at all. There are other significant differences between Raspberry Pi OS and Armbian. NetworkManager is the network management service. In addition networking configuration is done with netplan. I'll paraphrase the start of the description in the Netplan man page. It reads abstract network definitions written in YAML and converts them to actual configuration files for a specific networking service. Once these configuration files are written into the /run directory, the networking service starts using the newly written configuration. It sounds rather complicated, but as will be demonstrated it works. Just as in the previous section, we test that chrony will use a time server proposed by the DHCP server by removing all other time sources.

• Since the Orange Pi PC 2 is a server with a fixed address, it was necessary to make it a DHCP client
• All NTP time sources had to be removed from the chrony configuration files.
• Ensure that chrony picked up the NTP servers proposed by the DHCP server.

To remove the fixed IP address assigned to the Ethernet interface, eth0, nmtui, the NetworkManager configuration tool with a text user interface, could be used. Edit the appropriate connection, which here is called Wired&nbps;connection 1.

Then change the IPv4 configuration from <Manual> to <Automatic>. I prefered adding a couple of lines in the interfaces configuration file to achieve the same end.

Explicit NTP server addresses can be found in the configuration file chrony.conf. They will be lines that begin with either poll or server. Other sources can be listed in files in the /etc/chrony/sources.d directory and ending with the .sources extension. The following verifies that no such explicit time sources remain.

Finally let's make sure that chrony will use the NTP servers obtained from the DHCP server.

It was not necessary to add that line, it was already present.

After rebooting, it was obvious that the local time server was being used by chrony.

Finally, I found it interesting to look at which DHCP client is used and at the file written to the /run directory.

ntp

The ntp client that is installed on my desktop Linux Mint computer is similar to chrony although one could argue that it is slightly less elegant. The complete configuration file, /etc/ntp.conf is copied to /run/ntp.conf.dhcp if the DHCP server returned a list of NTP time sources (option 42). That list of discovered sources is injected into the copied configuration file as the first command as shown below.

As can be seen I had removed all other time sources, so that only the local time server is used.

Just when the system clock was deemed synchronized can't be said with certainty, but according to the two checks done above, it took less than three hours.

tasmota

This section will be short. Tasmota does not support this feature. According to Jason2866 in an answer to the Timezone not set form (sic) NTP server #14804 discussion, Tasmota does not support getting NTP servers via DHCP. This feature was removed since many routers does not support (correctly). This generated issues. You have to set via command see documentation. Of we have already seen how to set the NTP servers explicitely so there's no need to repeat that here.

Practical Considerations

The above has all been about testing the addition of a local time server. But what would be a good configuration? Recall that this adventure into the world of clocks began in the previous post where I professed wanting to be a good Internet citizen by setting up a local NTP server to fulfill all NTP requests from the many devices on our home network. Here is how I would like to do it.

1. One NTP server MUST be setup on the local network. Call this server LNTP.
   • The machine hosting LNTP MUST to be on at all times.
   • The LNTP SHOULD have access to the Internet to "discipline" its own clock using external time sources.
   • The LNTP MUST have access to the GPS based local NTP server (GNATS or better) as a back up.
   • The LNTP MUST be accessible from all devices connected to the LAN.
   While it may be prefereable that LNTP be on a router, but it could be on a NAS or the host of a home automation system. Access to LNTP from within the LAN will not be a problem with the typical flat configuration in most homes, but if subnets or VLANs are in place then appropriate firewall rules and routing will be needed.
2. The LAN's DHCP server SHOULD forward the LNTP IP address to DHCP clients.
3. All devices permanently connected to the LAN MUST use the LNTP as a time source.
4. All devices permanently connected to the LAN MUST NOT access external time sources. They COULD use the GPS based NTP server as a time source in addition to LNTP.
5. Portable devices SHOULD accept DHCP forwarded time sources.
6. Where it is not possible to enable use of DHCP supplied time sources, LNTP SHOULD be added to the list of time sources of portable devices.

I am planning to create a home lab (and this) in the near future that will be based on pfSense or OPNsense. Consequently, that list of MUSTs and SHOULDs may be modified as well as some of the instructions above. In the meantime, here is how I tested some of these ideas with the old OpenWRT router.

The image on the left (or top) shows how to enable the NTP client and server in the router which takes care of point 1. Do not pay attention to the URLs to external time sources. What is shown is not what is typically done and I have yet to investigate the best way to select public NTP servers. The image on the right shows that the DHCP server on the router will provide its own IP address as a time source to its client, which takes care of point 2. The image below is a simplified representation of how it would work.

GNATS, a Tiny Basic ESP32 GPS Based NTP Server