Have I found a bug or an undocumented feature? Or is my
understanding / expectation at fault?
On 2024-06-09, Roger <invalid@invalid.invalid> wrote:
Have I found a bug or an undocumented feature? Or is my
understanding / expectation at fault?
What's the output of "ntpd --version". You might be running into bug 3868 ><https://bugs.ntp.org/show_bug.cgi?id=3868>, the fix for which is in ntpd >4.2.8p18.
On 2024-06-09, Roger <invalid@invalid.invalid> wrote:
Have I found a bug or an undocumented feature? Or is my
understanding / expectation at fault?
What's the output of "ntpd --version". You might be running into bug 3868 ><https://bugs.ntp.org/show_bug.cgi?id=3868>, the fix for which is in ntpd >4.2.8p18.
On Sun, 9 Jun 2024 18:50:39 -0000 (UTC), Edward McGuire
<metaed@metaed.com> wrote:
On 2024-06-09, Roger <invalid@invalid.invalid> wrote:
Have I found a bug or an undocumented feature? Or is my
understanding / expectation at fault?
What's the output of "ntpd --version". You might be running into bug 3868 >><https://bugs.ntp.org/show_bug.cgi?id=3868>, the fix for which is in ntpd >>4.2.8p18.
Sorry, I should have included that. ntpd 4.2.8p18@1.4062
In the UK pool Leo Bodnar has 5 consecutive IP addresses:
85.199.214.98 - 85.199.214.102
restrict default nopeer noquery nomodify notrap limited kod
restrict source noquery nomodify notrap limited kod
restrict 85.199.214.96 mask 255.255.255.248 ignore
Does not stop those servers from being mobilized.
On 2024-06-10, Roger <invalid@invalid.invalid> wrote:
In the UK pool Leo Bodnar has 5 consecutive IP addresses:
85.199.214.98 - 85.199.214.102
restrict default nopeer noquery nomodify notrap limited kod
restrict source noquery nomodify notrap limited kod
restrict 85.199.214.96 mask 255.255.255.248 ignore
Does not stop those servers from being mobilized.
I, too, restricted those IP addresses restricted, but I didn't think of trying >to use a single entry to do it, so I didn't run into your problem. I think the >behavior you're seeing is consistent with the sometimes counterintuitive way >ntpd matches a given peer against the ACL.
"The ntpd daemon implements a general purpose access control list (ACL) >containing address/match entries sorted first by increasing address values and >then by increasing mask values. A match occurs when the bitwise AND of the mask
and the packet source address is equal to the bitwise AND of the mask and >address in the list. The list is searched in order with the last match found >defining the restriction flags associated with the entry." ---access.html
With this in mind, your first example creates the ACL:
address mask count flags
=====================================================================
0.0.0.0 0.0.0.0 0 noquery, nopeer, nomodify, notrap, limited, kod
85.199.214.96 255.255.255.248 0 ignore
When NTP Pool Project hands you 85.199.214.98, your "restrict source" applies to
it, and the ACL is now:
address mask count flags
=====================================================================
0.0.0.0 0.0.0.0 0 noquery, nopeer, nomodify, notrap, limited, kod
85.199.214.96 255.255.255.248 0 ignore
85.199.214.98 255.255.255.255 0 source, noquery, nomodify, notrap, limited, kod
These three entries all match 85.199.214.98. But it's the last match that >defines the restriction flags. So instead of the desired result "ignore" you get
"source, noquery, nomodify, notrap, limited, kod".
This is what I believe is going on. We'd like to be able to ignore an address >block using the netmask, but we can't. This may be where we throw up our hands >and chant "it's not a bug, it's a feature."
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 997 |
Nodes: | 10 (0 / 10) |
Uptime: | 219:32:54 |
Calls: | 13,045 |
Files: | 186,574 |
Messages: | 3,292,528 |