Should the reference_timestamp & reference_id be set in server only mode?

[o087D]

I am attempting to configure ntpd-rs as a server for a system where the system time is being conditioned by gpsd.

My configuration is:

source = []

[observability]
log-level = "info"
observation-path = "./observe"

[[server]]
listen = "[::]:123"

[synchronization]
local-stratum = 1

The response packets from ntpd making a request are parsed by wireshark as being:

Reference ID: Unidentified reference source 'XNON'
Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC

And the error I am getting from ntpdate is:

192.168.45.100: Server dropped: Server has gone too long without sync

(I know ntpdate is deprecated, but I believe it should still work?) The offending area in ntpdate is:

		if ((server->org.l_ui - server->reftime.l_ui)
		    >= NTP_MAXAGE) {
			if (debug)
				printf("%s: Server dropped: Server has gone too long without sync\n", 
				       ntoa(&server->srcadr));
			continue;	/* too long without sync */
		}

Where NTP_MAXAGE is set to 1 day. I do not think check is present in ntpd itself.

According to RFC5905:

   Reference Timestamp: Time when the system clock was last set or
   corrected, in NTP timestamp format.

Digging around I think the response builder (https://github.com/pendulum-project/ntpd-rs/blob/main/ntp-proto/src/packet/mod.rs#L233) is settings this to default and there is no other mechanism to configure it.

Would you be amenable to a stopgap PR which set the reference_timestamp to the receive_timestamp? (i.e. in the absence of an exact time the clock was last updated we can go with something very recent, rather than the epoch)

I would also like to add a configuration option to allow the reference ID word to be set in the [[server]] section of the configuration via a string.

Finally, if the server is running with established sources the reference_timestamp could be set to the actual time of the last completed poll event - but I have not looked in to the mechanics of that and expect there to be some cross-thread shenanigans required.

If these are of use I can find some time to do the work.

[davidv1992]

We don't use the reference timestamp in ntpd-rs, as putting an accurate timestamp in that field leaks information that may make certain types of attacks significantly easier. I did not realize that this field was actually used by any implementation, as the ntpv4 standard does not.

What you describe as a stopgap PR actually seems to me like a very good solution, also long term. In the very long term the field will disappear anyway, as it is currently slated to be removed in ntpv5.

[davidv1992]

As for adding a configuration option for setting the reference, I think we would be open to that, though for technical reasons we should probably not have it be part of the server section, but rather the synchronization section. We may also want to have a look at how we want this to behave exactly (should it just be an initial value, or a complete override). Feel free to open a feature request issue for this.

[rnijveld]

Just as an aside: you really should try and get away from ntpdate. It very much is deprecated, most modern Linux distributions no longer ship it at all (and haven't for a couple of years). It doesn't protect your system against weird time jumps at all. Even just switching to something like systemd-timesyncd would help a lot.

[o087D]

Just as an aside: you really should try and get away from ntpdate. It very much is deprecated, most modern Linux distributions no longer ship it at all (and haven't for a couple of years). It doesn't protect your system against weird time jumps at all. Even just switching to something like systemd-timesyncd would help a lot.

Ideally yes - hence the interest in ntpd-rs - but many of the products I work with are unlikely to get complete system updates, so compliance is with the RFC is the only thing I can go on (in the hope that their ntp solution is compliant that is - the likes of Yocto and Busybox based builds are prevelant).

In any case, the "Reference ID" is not nearly as simple as it looked on first pass - and an incomplete implementation is much worse than a technically correct solution, so this might take a little more time than I had expected!