• restrict ... mask ... ignore ideocyncrasy

    From Roger@invalid@invalid.invalid to comp.protocols.time.ntp on Sun Jun 9 18:59:12 2024
    From Newsgroup: comp.protocols.time.ntp

    This combination of lines doesn't work as I expect. It does not
    stop pool servers from that address block from being mobilized.

    restrict default nopeer noquery nomodify notrap limited kod
    restrict source noquery nomodify notrap limited kod
    restrict 198.51.100.0 mask 255.255.255.0 ignore


    The following does work. Remove the "restrict source" line
    completely and remove "nopeer" from the "restrict default"
    line.

    restrict default noquery nomodify notrap limited kod
    restrict 198.51.100.0 mask 255.255.255.0 ignore


    Have I found a bug or an undocumented feature? Or is my
    understanding / expectation at fault?
    --
    Roger
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Edward McGuire@metaed@metaed.com to comp.protocols.time.ntp on Sun Jun 9 18:50:39 2024
    From Newsgroup: comp.protocols.time.ntp

    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.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Roger@invalid@invalid.invalid to comp.protocols.time.ntp on Mon Jun 10 07:45:10 2024
    From Newsgroup: comp.protocols.time.ntp

    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
    --
    Roger
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Roger@invalid@invalid.invalid to comp.protocols.time.ntp on Mon Jun 10 08:16:24 2024
    From Newsgroup: comp.protocols.time.ntp

    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.

    Additional thoughts. Compiled from source code, MD5 and SHA256
    agree with what Harlan Stenn posted on 26th May.

    Individual IP addresses do not get mobilized; the two addresses
    below would be ignored. It's "restrict ... mask ... ignore"
    which doesn't "work".

    restrict default nopeer noquery nomodify notrap limited kod
    restrict source noquery nomodify notrap limited kod
    restrict 198.51.100.65 ignore
    restrict 198.51.100.79 ignore
    --
    Roger
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Roger@invalid@invalid.invalid to comp.protocols.time.ntp on Mon Jun 10 11:44:03 2024
    From Newsgroup: comp.protocols.time.ntp

    On Mon, 10 Jun 2024 07:45:10 +0100, Roger
    <invalid@invalid.invalid> wrote:

    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

    I went back to p17 to compare it's behaviour with p18. No
    difference.

    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.

    restrict default noquery nomodify notrap limited kod
    restrict 85.199.214.96 mask 255.255.255.248 ignore

    Stops them from being mobilized.

    restrict default nopeer noquery nomodify notrap limited kod
    restrict source noquery nomodify notrap limited kod
    restrict 85.199.214.98 ignore
    restrict 85.199.214.99 ignore
    restrict 85.199.214.100 ignore
    restrict 85.199.214.101 ignore
    restrict 85.199.214.102 ignore

    Stops them from being mobilized.

    Hope that helps.
    --
    Roger
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Edward McGuire@metaed@metaed.com to comp.protocols.time.ntp on Mon Jun 10 19:09:16 2024
    From Newsgroup: comp.protocols.time.ntp

    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."
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Roger@invalid@invalid.invalid to comp.protocols.time.ntp on Mon Jun 10 21:09:47 2024
    From Newsgroup: comp.protocols.time.ntp

    On Mon, 10 Jun 2024 19:09:16 -0000 (UTC), Edward McGuire
    <metaed@metaed.com> wrote:

    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.

    If you are using the UK pool then restrict 87.75.224.75 as well
    as that always sends poll 4.

    "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

    I saw that but my eyes glazed over and my brain went on holiday.

    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."

    Thank you for the explanation; it would have taken a very long
    time for me to work it out for myself.

    In the meantime, I think my subconscious must use the motto "if
    it ain't broke, twiddle the knobs until it does". Then I have to
    hope that there's someone cleverer than me who can explain what
    is going on.
    --
    Roger
    --- Synchronet 3.20a-Linux NewsLink 1.114