The NTP Time Offset Feature

While the NTP protocol normally works with UTC only, the NTP daemon (ntpd) that is included in current versions of the firmware for Meinberg LANTIME devices has an extension that can be used to let the NTP server optionally provide non-standard time.

This time offset feature can be used to provide particular clients with times that have specific offsets from UTC, for example to let some NTP-controlled displays show local time instead of UTC. Whether an offset is applied, or not, can be configured depending on a range of local or remote IP addresses.

Please note that this feature must not be used to synchronize the times of computers, because for this original purpose, NTP is expected to only provide the operating system with UTC, and local time is derived by the OS depending on the users' preferred timezone settings.

The time offset configuration file /etc/ntp_time_offs.conf on the LANTIME is a simple text file that can contain one or more configuration lines, each of which specifies

• A local or remote IP address range
• A standard time offset that is applied by default
• Optionally, a time stamp when the applied offset has to change, as well as
  another offset to be applied if the current time is after that time stamp.

Here is an example configuration with 2 lines:

rmt 192.168.5.0/16 3600 1628178060 7200
lcl 172.29.4.0/24 -100

Each line has to start with rmt or lcl to indicate whether the rule specifies a remote address range, i.e. a range of addresses from which client requests are sent, or an address range of the local interface(s), i.e. at which the request packets from the clients come in.

The second field contains the IPv4 or IPv6 address range in CIDR notation, where the number of bits for the net mask is appended after a slash (/) to specify the range of IP addresses for which this rule is to be applied.
For details, see below.

The third field specifies the time offset, in seconds, that is added to the time that is sent in response to the client request originating from or arriving via the specified IP address range.

The optional forth and fifth fields can be used to specify a point in time after which a different offset is to be applied. This can be used to let the local time sent to clients be automatically changed e.g. when daylight saving (DST) begins or ends.

If these fields are omitted, only the first (standard) time is applied all the time.

The CIDR address in a configuration line is used to determine a range of IP addresses for which the specified time offset has to be applied.

The number of net mask bits just determines the number of IP addresses in a range of addresses, and is neither related to the real net mask of the underlying network, nor to the physical or logical interface that is used for the packet exchange.

For example, with a configuration rule like

rmt 192.168.5.0/24 3600

with a 24 bit net mask, which usually specifies a full class C subnet (net mask 255.255.255.0), a 3600 s offset is applied for all clients that send requests from any IP address in that subnet, i.e. in the range 192.168.5.1 to 192.168.5.254.

If the rule has a tighter net mask, e.g.

rmt 192.168.5.0/28 3600

with a 28 bit net mask, only clients that send requests from IP addresses in the range 192.168.5.1 to 192.168.5.15 get the time with an offset, while clients sending from IP addresses 192.168.5.16 to 192.168.5.254 get standard UTC time, as usual.

If only requests from a single IP address are to be served with an offset, the IP address needs to be specified with the full net mask, e.g. /32 for IPv4:

rmt 192.168.5.13/32 3600

With the configuration line above, only client requests sen from IP address 192.168.5.13 receive the time with the specified offset, all other clients get UTC time, regardless of the subnetting of the physical network.

The same rules apply to local addresses. If the NTP server has several network interfaces, it doesn't matter at which interface a request from a client is received. Only the IP address is important:

lcl 172.29.4.0/24 3600
lcl 172.29.5.1/32 -100
lcl 172.29.5.2/32 +100
lcl 172.29.5.3/32 -150

In the example above, all requests that come in via a local IP address in the range 172.29.4.1 to 172.29.4.254 receive a response with an offset of 3600 s.

All requests that arrive via IP address 172.29.5.1 get a response with offset -100 s, requests coming in via 172.29.5.2 get a response with offset +100 s, and so on.

The time stamp of the switching time has to be specified as UTC in POSIX format, i.e. the number of seconds of 1970-01-01.

On a standard Unix/Linux system (e.g. in an SSH session on the LANTIME) the following command can be used to determine the appropriate time stamp:

date -u -d '2021-08-05 15:41:00' +%s
1628178060

The inverse command below can be used to convert a time stamp from a line of the configuration file to human readable calendar date and time:

date -u -d @1628178060
Thu Aug  5 15:41:00 UTC 2021

When ntpd reads the time offset configuration file, it builds lists of IP address ranges which are examined whenever a client request is to be handled.

When a client request is received, first the list of remote IP addresses is examined to see if the IP address from which the request was sent matches one of the configured ranges.

Only if no match is found for the remote address, the list of local IP addresses is searched to see if the local IP address at which the packet arrived is included in one of the configured local address ranges.

If any match is found, the associated time offset is applied to the time in the response packet sent to the NTP client.

If no match is found at all, or if the lists are empty anyway, no time offset is applied, so by default the NTP server behaves as usual.

The lists are searched before the transmit timestamp are taken, so this feature doesn't affect the resulting accuracy at the client side.

The NTP daemon (ntpd) reads the configuration file at startup, and again whenewer it receives a SIGPWR signal, sent e.g. by executing the command

kill -PWR `pidof ntpd`

So after the configuration file has been changed, it is sufficient to run the command above to let ntpd re-read the configuration file. It is not necessary to restart the daemon.

The time offset feature is not yet supported on the SyncFire versions of the LANTIME devices.

Which level of implementation is supported by a specific LANTIME firmware version can be determined from the exact version of the NTP daemon (ntpd) running on the machine, for example by running the command ntpd –version in an SSH session on the LANTIME, for example:

# ntpd –version
ntpd 4.2.8p15-mbg-01-o Wed Jul 15 10:16:17 UTC 2020 (2)

In the example above, the relevant version information is 4.2.8p15-mbg-01.

Supports a configuration file that can contain many remote and/or local address ranges.

Unlike with earlier versions, overlapping IPv4 or IPv6 address ranges are automatically sorted so that the narrowest range is matched first.

This older version supports a configuration file that can contain many remote and/or local address ranges.

However, overlapping IPv4 or IPv6 address ranges are not automatically sorted, so they need to be specified in the configuration file in the correct order, with the narrowest range first.

This is the initial version that supports this feature. However, it only supports a configuration file with a single remote IP address range and a single local IP address range.

— Martin Burnicki martin.burnicki@meinberg.de, last updated 2021-08-12