Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s

[Dave Hart]

On Tue, 22 Aug 2023 at 18:48, Edward McGuire  wrote:

> ntpq> :config restrict 17.253.2.123 ignore
> ntpq> :config unpeer 17.253.2.123
>
> ultimately doesn't work. The "unpeer" drops the pool peer, but later the
> pool peer is "rediscovered" despite the "restrict ignore". Apparently the
> client maintains the association indefinitely. Evidence for this is that
> "ntpdc -n -c reslist" returns:
>
> 17.253.2.123   255.255.255.255 0  ignore
> 17.253.2.123   255.255.255.255   366  source, noquery, nomodify,
> notrap, limited, kod
>
> The first entry is the "restrict ignore" ACE I entered manually. The
> second is the "restrict source" ACE that still exists even after the
> "unpeer".
>

If that restrict source entry outlives the unpeer that's definitely a bug
to be fixed as well.  If you see it only when that server is actually being
used, that's expected as things stand but I'd like to change it so we
wouldn't use a pool server with an "ignore" restriction already in place.

Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s

[Dave Hart]

On Tue, 22 Aug 2023 at 18:48, Edward McGuire  wrote:

> I'm coming back to this issue because the solution I tried:
>
> ntpq> :config restrict 17.253.2.123 ignore
> ntpq> :config unpeer 17.253.2.123
>
> ultimately doesn't work. The "unpeer" drops the pool peer, but later the
> pool peer is "rediscovered" despite the "restrict ignore". Apparently the
> client maintains the association indefinitely. Evidence for this is that
> "ntpdc -n -c reslist" returns:
>
> 17.253.2.123   255.255.255.255 0  ignore
> 17.253.2.123   255.255.255.255   366  source, noquery, nomodify,
> notrap, limited, kod
>
> The first entry is the "restrict ignore" ACE I entered manually. The
> second is the "restrict source" ACE that still exists even after the
> "unpeer".
>
> Short of restarting NTP, or adding an entry to my nftables firewall, is
> there a way to drop the association with the bad peer so it doesn't keep
> coming back?
>
>
I don't know of one, but a better solution to me is that the "restrict
source" restriction shouldn't be added if there's already a host-specific
restriction in place.  Please file a bug report requesting this.

[questions] Re: one pool peer polled at 64 s, others all 1024 s

[Edward McGuire]

I'm coming back to this issue because the solution I tried:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config unpeer 17.253.2.123

ultimately doesn't work. The "unpeer" drops the pool peer, but later the pool 
peer is "rediscovered" despite the "restrict ignore". Apparently the client 
maintains the association indefinitely. Evidence for this is that "ntpdc -n -c 
reslist" returns:

17.253.2.123   255.255.255.255 0  ignore
17.253.2.123   255.255.255.255   366  source, noquery, nomodify, notrap, 
limited, kod

The first entry is the "restrict ignore" ACE I entered manually. The second is 
the "restrict source" ACE that still exists even after the "unpeer".

Short of restarting NTP, or adding an entry to my nftables firewall, is there a 
way to drop the association with the bad peer so it doesn't keep coming back?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: one pool peer polled at 64 s, others all 1024 s

[Edward McGuire]

On Tuesday, October 25, 2022 at 10:34:35 AM UTC-5, Roger wrote:
> The server you mentioned is, I think, in New York City

It's usnyc3-ntp-003.aaplimg.com, an Apple time server, located in New York City 
just as you said. It is listed in the pool, along with various other clocks 
operated by Apple, ISC, Hurricane Electric, Turkcell Superonline, and RIPE, in 
the name of one person, "possibly" without permission.

:(

Apparently, adding a server to the pool currently requires no proof that you 
are the server operator (see: 
).

:O===

Pool admins can be alerted to listings needing review, using the form at 
, which I have now done.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s

[David Hart]

On Tue, Oct 25, 2022, 12:35 AM David Hart  wrote:

>
>
> On Mon, Oct 24, 2022, 6:39 PM Edward McGuire  wrote:
>
>> Without checking the source, I presume this is because access control is
>> enforced only at association creation time.
>>
>
> That is correct.
>

I think I oversimplified there a bit. I suspect what is happening is the
restrictions do not apply to upstream servers or which the client maintains
an association. They are applied for downstream. Client requests where
there is no existing association.

Dave

>

Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s

[David Hart]

On Mon, Oct 24, 2022, 6:39 PM Edward McGuire  wrote:

> On Monday, October 24, 2022 at 4:15:06 PM UTC-5, Roger wrote:
> > I asked about this back in April this year. It's the way the servers
> have been set up; the servers I have observed always return a poll of 4
>
> Thank you! I went back to the April thread, and learned these peers are
> actually not adhering to protocol. Not causing a problem that I see,
>

This doesn't surprise me. Yesterday I was reading the source code for an
RTOS- based NTP embedded device. Both the client and server code were
extremely minimal, covering only the most common use case of unicast
clients against a GPS stratum one server. There was no PLL or any of the
other NTPv4 filtering and selection logic.  The host clock was maintained
in NTP wire format and directly updated from the GPS with no slewing.


Without checking the source, I presume this is because access control is
> enforced only at association creation time.
>

That is correct.

Cheers,
Dave Hart.

[questions] Re: one pool peer polled at 64 s, others all 1024 s

[Edward McGuire]

On Monday, October 24, 2022 at 4:15:06 PM UTC-5, Roger wrote:
> I asked about this back in April this year. It's the way the servers have 
> been set up; the servers I have observed always return a poll of 4

Thank you! I went back to the April thread, and learned these peers are 
actually not adhering to protocol. Not causing a problem that I see, but out of 
an abundance of caution I want to punch out nonconforming peers. Today's was 
17.253.2.123, returning a poll of 6. Here was my experience.

After adding "restrict 17.253.2.123 ignore" to ntp.conf, I tried to punch the 
peer out dynamically, but neither of these worked on their own:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config restrict 17.253.2.123 limited kod nomodify notrap nopeer noquery

Without checking the source, I presume this is because access control is 
enforced only at association creation time. So I've done:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config unpeer 17.253.2.123

and of course that did delete the association. Now I'll just have to keep an 
eye on the peer list and see if it comes back.

Cheers!
Edward
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org