Re: Routing socket issue?

[Roy Marples <roy%marples.name@localhost>]

On 30/01/2021 22:01, Frank Kardel wrote:
> "why it needs to be interested i..."
>
> Ntpd needs to know the local address being used when sending to peers 
> (authentication, which socket to use). That is why it not just reacts to
>
> address information but also redetermines to local addresses (and sockets) are 
> being used for reaching its peers.
>
> The interaction with the routing socket is purposely simple. ntpd just needs to 
> know that *something* has changed. It will then rescan after a grace period the 
> interfaces and reevaluate
>
> the interface/local address/socket setup. It does not need to be extremely 
> snappy but it needs to happen.
>
> Dropping that might delay ntpd's detection of changed local addresses for peers.

For example I fail to see how RTM_LOSING helps that because it won't change
how ntpd would configure itself.

As NTP doesn't bring interfaces up or down, RFM_IFANNOUNCE is useless as well.
If the interface does vanish, any addresses on it will be reported via RTM_DELADDR.
RTM_IFINFO is also questionable as commentary in the code is that it only cares 
about addresses.

NOTE TO SELF: our kernel doesn't seem to report RTM_CHGADDR anymore looking at 
nxr.netbsd.org

I mean, if you want to argue against any of that then I would suggest why even 
bother filtering or looking at overflow at all?
Shrink the code - any activity on the routing socket, drain it ignoring all 
error, start the interface update timer.

> As for the message: IMHO it does not need to be logged at all (DPRINTF/maybe 
> LOGDEBUG at most) because the overflow should and does just trigger ntpd to 
> reevaluate the interface/routing configuration.
>
> This information is not important at all for normal operation as the effects are 
> correctly mitigated.

Great.

> BTW: does the current code revert to (fail safe) periodic interface scanning if 
> the routing socket is being disabled (happens when an unexpected error code is 
> returned from read(2))?

No.

The socket is non blocking so the only error to ignore here would be EINTR.
Any other errors are due to bad programming IMO.

Roy