Even after otto@'s commit in -current... If no replies are received for a while due to connectivity issues go into unsynced mode. The existing code to check if we're unsycned is only done on receiving an ntp packet which does not happen if there are connectivity issues.
... ntpd can still fail to recognize that a server is unreachable. 36 hours after packets to the server have been blocked, ntpd still pretends that nothing is wrong: ----------------------------- 1/1 peers valid, clock synced, stratum 2 peer wt tl st next poll offset delay jitter fddd:28ee:243:2:213:95ff:fe06:1bb7 ntp * 1 10 1 2201s 3296s -0.068ms 1.346ms 0.438ms ----------------------------- ===> What works If I use pf(4) to block outgoing packets on the client (block return out proto udp to port ntp), ntpd quickly invalidates the peer. ktrace of the ntp engine process shows this pattern: 23799 ntpd CALL sendto(6,0x278c98a1784,0x30,0,0,0) 23799 ntpd RET sendto -1 errno 65 No route to host ... 23799 ntpd CALL recvmsg(6,0x7f7ffffddd60,0) 23799 ntpd RET recvmsg -1 errno 61 Connection refused ===> What doesn't work If I block incoming NTP packets on the gateway to the server (block return on $if proto udp to port ntp), ntpd does not notice that the peer is unavailable. tcpdump shows the expected ICMP error responses to the NTP queries. ktrace of the ntp engine process shows this pattern: 23799 ntpd CALL sendto(6,0x278c98a1784,0x30,0,0,0) 23799 ntpd RET sendto 48/0x30 ... 23799 ntpd CALL recvmsg(6,0x7f7ffffddd60,0) 23799 ntpd RET recvmsg -1 errno 61 Connection refused Tentative conclusion: ntpd notices when it can't send queries to the server, but not when it fails to receive replies. -- Christian "naddy" Weisgerber na...@mips.inka.de
