Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s
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
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.
Re: [questions] Re: one pool peer polled at 64 s, others all 1024 s
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
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.
