I had sent an email to some email address from the project but I figured I’d also talk about it here.
For the past week or so some of our endpoints have gotten horribly wrong times. Upon looking at all the NTP traffic, it look to me like the NTP server at 23.186.168.123 is providing wrong times. Here’s an example of a packet I observed:
This is a Windows Server instance. As far as I know everything is good on our end, but I’m more than welcoming ideas of things for me to check.
From what I can see the server often sends the right time (it is sending the right time right now, for example), but then also sometimes sends the wrong time:
When a single server supposedly being wrong can cause issues, that usually means that the client is a simple SNTP client only, or a badly configured NTP client. I don’t recall anymore what type the client in Windows is. It used to be a simple SNTP client, but recent Windows versions introduced a “high precision” mode (that I think needs to be enabled explicitly), not sure whether that is a proper NTP client.
Either way, maybe it is an option to run Meinberg’s build of the ntpd classic version for Windows, rather than using Windows’ built-in client. ntpd classic would be a proper NTP client supporting multiple upstreams and mechanisms to guard as much as possible against single falsetickers.
I have seen Windows itself not requesting time properly, often goes wrong.
Therefor many radio-amateurs that need precise time do not use the windows ntp-client but install a separate program/client to keep windows running proper time.
By the way, what do you mean by “terribly wrong”? I.e., wrong by how much?
You show the NTP packets, but I don’t see anything wrong (though I am admittedly always confused by how the fields are populated, especially how the server transfers data received in the request into the response).
If I am not mistaken, the “origin timestamp” in a server’s response is actually the timestamp that the client provided. And since the client knows (or should know) when it sent the request, modern clients don’t populate that field with a proper timestamp anymore, but, e.g., use a random value to guard against certain types of attacks against the client.
E.g., see attached screenshot showing an origin timestamp, provided by the client, many years in the future:
Or do you mean that that shows that the client is keeping bad time? Or is the client’s time in that timestamp actually correct, and the other timestamps (provided by the server) are wrong?
Another strange thing generally, but without knowing more about the client not necessarily bad: It seems the client is not sending “normal” NTP client requests, but rather so-called “symmetric” requests (since the server is responding with a “symmetric passive” mode message). “symmetric” mode is typically only used between peers that are explicitly configured to use that mode with each other, not by a typical client contacting some “random” anonymous server.
I monitor NTP pool servers independently from the public monitoring system. During the month of July, 23.186.168.123 reported reference IDs of 132.163.97.4 / .6
Root dispersion was under 6 msec. Root distance was under 42 msec.
Jitter was under 2 msec. Absolute accuracy is better than 10 msec.
I’d like to look at packet captures. The text decode provide shows “Mode: symmetric passive”.
It is more common to see client/server modes (modes 3 and 4).
Following the pointer to Windows time service troubleshooting info provided by Meinberg that @bas kindly provided, it seems that Windows clients by default use active symmetric mode packets. They can apparently be reconfigured to send proper client mode packets instead.
I did some more looking into this and found that the authoritative time source the NTP pool was being checked against itself was off! Just goes to show you you can never trust your independent “proof”.
This server is actually probably just fine, and what I was comparing its times to was off… so sorry everyone.
