Requesting code review on possible fix for nopeer/pool conflict

[Hal Murray]

dfoxfranke at gmail.com said:
> The whole receive() function you're looking at is about to get blown away in
> my ntp_proto refactor. Can you hold off on touching it until next week? 

Please don't push any big changes until Eric and/or I get the polling tangle 
fixed.


dfoxfranke at gmail.com said:
> One more reason I need to get my ACL language implemented and restrict needs
> to die. 

If you kill restrict, we are taking a major step toward making ntp.conf file 
no longer compatible.

Would it be possible to for your new code to support the old restrict stuff?  
(Similar to the way Eric's new refclock stuff still works with the old stuff.)

-------

> I think this working as designed. 'restrict nopeer' means "Don't establish
> unauthenticated ephemeral associations with this IP address", which is
> exactly what pool does. I agree this is stupid design but I don't think it's
> a bug.

I think the current setup is buggy, but maybe that whole area is more 
complicated than I currently understand.

Maybe restrict needs a nopool tag so we don't get confused by peer vs pool.

There is a fundamental problem here.  What should happen if server/pool and 
restrict lines conflict?  Is server DNS different from server IP Address?  My 
straw man is that a restrict line with explicit IP Address(es) should block 
server/pool addresses but the default restrict should not.

I'd also vote for conflicts to generate error messages at startup time and/or 
at DNS lookup time.  The DNS lookup could try the next address and/or try 
again later (after TTL).

-- 
These are my opinions.  I hate spam.