Hal Murray <hmur...@megapathdsl.net>:
>
> > 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);
> }
OK. I think your hole-filling might already be done in the restrict_source()
call here:
/*
* unpeer - remove peer structure from hash table and free structure
*/
void
unpeer(
struct peer *peer
)
{
mprintf_event(PEVNT_DEMOBIL, peer, "assoc %u", peer->associd);
restrict_source(&peer->srcadr, true, 0);
set_peerdstadr(peer, NULL);
peer_demobilizations++;
peer_associations--;
if (FLAG_PREEMPT & peer->flags)
peer_preempt--;
#ifdef REFCLOCK
/*
* If this peer is actually a clock, shut it down first
*/
if (FLAG_REFCLOCK & peer->flags)
refclock_unpeer(peer);
#endif
free_peer(peer);
}
> >> 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.
I'll take a doc patch to that effect; also please add this RFE to devel/TODO.
You make a good case, but I want to get our decks cleared of tracker issues
before we start in on stuff like this.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
