On Tue, Sep 01, 2020 at 06:33:34PM +0200, Christian Weisgerber wrote:
> 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 [email protected]
>
Yeah, this was my next step. client_dispatch() is a bit dumb in the
sense that it always returns 0, if it did something useful or not. Ot
should distinguis between packet processes ok, packet rejected for
some reason and error.
Note that a complete absense of a reply (with no icmp) does work and
sets the state to unsynced.
-Otto
