From Newsgroup: comp.protocols.time.ntp

A recent restart of ntpd using the pool resulted in me
seeing a sixth server in the uk pool returning poll 4.
There is code which clamps ntpd to minpoll for a server
which returns a poll which is less than the client poll.
My way of disabling such servers was to include "restrict
[ip address] ignore" in ntp.conf. Obviously not too
satisfactory as one needs to know about a server before
it can be included in the restrict list.

A couple of days ago it occurred to me that it would be
possible, although unlikely, for a pool client to end up
with all servers returning poll 4 and not being able to
move between minpoll and maxpoll.

The following patch stops ntpd from being clamped at
minpoll. I don't know enough about ntpd to know whether
there are modes which require the clamp but if there
are then a simple

if (some modes)
peer->ppoll = max(peer->minpoll, pkt->ppoll);

should do the job.

The patch works for me using the pool and I have removed the
restrict lines. It doesn't matter how many servers are
misconfigured in this fashion my client will work as designed.

I have read that there are unlikely to any more updates to
ntp-4.2.8 but perhaps this idea can be incorporated into
ntp-4.4 if considered correct and useful.

diff -Naur ntp-4.2.8p17-orig/ntpd/ntp_proto.c ntp-4.2.8p17/ntpd/ntp_proto.c >--- ntp-4.2.8p17-orig/ntpd/ntp_proto.c 2023-06-06 12:33:42.000000000 +0100 >+++ ntp-4.2.8p17/ntpd/ntp_proto.c 2024-04-30 12:11:32.402867197 +0100
@@ -2273,7 +2273,9 @@
sys_badlength++;
return; /* invalid packet poll */
}
+/***
peer->ppoll = max(peer->minpoll, pkt->ppoll);
+***/
if (kissCode == RATEKISS) {
peer->selbroken++; /* Increment the KoD count */
report_event(PEVNT_RATE, peer, NULL);

--
Roger
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.protocols.time.ntp

On 2024-05-01, Roger <invalid@invalid.invalid> wrote:

A recent restart of ntpd using the pool resulted in me
seeing a sixth server in the uk pool returning poll 4.

The LeoNTP units are known to do that or at least they used to do that
with some firmware versions.

The following patch stops ntpd from being clamped at
minpoll. I don't know enough about ntpd to know whether
there are modes which require the clamp but if there
are then a simple

if (some modes)
peer->ppoll = max(peer->minpoll, pkt->ppoll);

should do the job.

The symmetric mode needs this as messages are both requests and
responses at the same time. The poll value tells the other peer how
frequently it would like to get a response (which is a request of the
other peer) to finish its NTP measurement.

In the client-server mode it can be ignored, or used only as a hint for increasing the polling interval in order to avoid rate limiting. There
was an argument made that decreasing the interval could be useful with
leap smearing, allowing the server to reduce the client's polling
interval to make it better track the server's frequency adjustments in
the smear, but I'm not sure if it's worth the trouble with servers that
don't follow the specification.
--
Miroslav Lichvar
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.protocols.time.ntp

On Thu, 2 May 2024 07:00:31 -0000 (UTC), Miroslav Lichvar
<mlichvar@redhat.com> wrote:

On 2024-05-01, Roger <invalid@invalid.invalid> wrote:

A recent restart of ntpd using the pool resulted in me
seeing a sixth server in the uk pool returning poll 4.

The LeoNTP units are known to do that or at least they used to do that
with some firmware versions.

Leo's five ip addresses 85.199.214.98 - 102 certainly still
always send poll 4 as does 87.75.224.75 which is also in
the UK pool.

The following patch stops ntpd from being clamped at
minpoll. I don't know enough about ntpd to know whether
there are modes which require the clamp but if there
are then a simple

if (some modes)
peer->ppoll = max(peer->minpoll, pkt->ppoll);

should do the job.

The symmetric mode needs this as messages are both requests and
responses at the same time. The poll value tells the other peer how >frequently it would like to get a response (which is a request of the
other peer) to finish its NTP measurement.

That makes it clear that an "if" would be needed.

In the client-server mode it can be ignored, or used only as a hint for >increasing the polling interval in order to avoid rate limiting. There
was an argument made that decreasing the interval could be useful with
leap smearing, allowing the server to reduce the client's polling
interval to make it better track the server's frequency adjustments in
the smear, but I'm not sure if it's worth the trouble with servers that
don't follow the specification.

Thank you for your explanation.
--
Roger
--- Synchronet 3.20a-Linux NewsLink 1.114