pool and restrictions

Hal Murray hmurray at megapathdsl.net
Tue Aug 15 19:02:20 UTC 2017


> Fair enough.  I have an idea for a simple way to implement this.  But I
> can't find where the hole-poking is actually being done - it's apparently
> not via a hack_restrict() call, which is what I'd have expected.  Can you
> give me a file and line number? 

ntp_proto.c, line 2480, in dns_take_pool
        restrict_mask = restrictions(&peer->srcadr);
        /* FIXME-DNS: RES_FLAGS includes RES_DONTSERVE?? */
        if (RES_FLAGS & restrict_mask) {
                msyslog(LOG_INFO, "Pool poking hole in restrictions for: %s",
                                socktoa(&peer->srcadr));
                restrict_source(&peer->srcadr, false,
                                current_time + POOL_SOLICIT_WINDOW + 1);
        }

-----------


>> Maybe we should add another flag to disable poking holes.
>> Maybe it's an enhancement rather than bug fix, but this would
>> be the time to do it.
> I'm generally opposed to adding more interface knobs.  The configuration
> language is tricky enough as it is.  Why do you think we might need one? 

With the current setup, restrict is essentially ignored for pool hosts.  
There is no way to say "I want to use the pool, but skip hosts at 
a.b.c.d/16".  It will poke a hole in that restriction.  You might want to do 
that because your routing to there is crappy so you get crappy time.  Or 
maybe they are known bad guys and the pool operators are slow to respond or 
don't think they are bad enough to kick out or ...

I generally agree with your more knobs comment.  This might be filling in a 
hole and thus make things cleaner overall rather than more complicated.

If we don't fix this, we should at least make sure the documentation is clear.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list