[ntp:hackers] [Bug 1378] Unnecessary resetting of peers during interface update

Frank Kardel kardel at ntp.org
Sun Nov 15 22:14:13 UTC 2009


Danny Mayer wrote:
> Dave,
>
> I agree with most of what you said. The concern has been almost
> exclusively with static servers that are using broadcast/multicast
> client mode and autokey so clearing the association when no local
> address has changed causes an authentication reset as well as the
> clearing of all history regardless of the information already collected
> about the remote server.
Well, as Dave said and what we discussed July 2007 the only requirement
is to reset authenticated associations.
We could limit that easily.
>  Part of the problem with howland was that it
> was associating the multicast address with the wildcard address which is
> wrong since you cannot use the wildcard address for authentication.
That probably lead to wrong local addresses linked to peers via findpeer().
>  The
> system would get jerked around every 5 minutes and never be able to
> synchronize. While we have corrected the wildcard address issue, the
> problem of changing multicast associations even when no local address
> has changed remained. I changed the code to do nothing if there were no
> local address changes
Would it be possible to get a log showing the actions at -D5 ?
>  Frank objected to that because you might be able
> to take advantage of a new route if the routing changed. My biggest
> objection to that is by resetting the association you have just lost all
> of the work done to amortize the jitter, delay, etc. of the association
> and I don't consider it important enough to worry about different
> routing unless the remote server becomes unreachable for any reason.
Well, that would be taken care of if we limited peer_clear() to
cryptographic associations.
>  One
> method of addressing this is to see if a different route is available
> (ie via a different address)
How would you do that? ntpd should stick to the mechanism used at
configuration time and repeat that when necessary. I'd rather not add
another network detection mechanism there that would differ in behavior
from a plain new address configuration at the time of address change
detection.
>  and only then reset the association if the
> local address to be used had changed and the remote server is not
> reachable. 
I would imagine, that is not trivial to do - another stage of deferring
local address changes until a peer is deemed unreachable -That might
take some time for the reach register to clear. I could imagine that
people might ask why it take so long to follow a ppp dynamic address. I
don't see any advantage in delaying the change - especially if we don't
reset  non-cryptographic assiciations.
> For broadcast and multicast addresses the other part of this
> is if the interface to be used could have changed. I think all of this
> is much more complicated than the logic that Frank currently has in
> place since
Could you give any precise hints on what is not handled correctly
(except for too aggressive peer_clearing()) - preferrably  with logfile
evidence ? I'd rather work from facts that from fiction.

The existence of many examples/cases does not mean that code needs to be
overly complicated.

There are not so many exceptions to consider. peer_clearing() can be
reduced to cryptographic associations. The other exceptions are cast
reception and initial volley(calibration and autokey). The effects of
these are located in findpeer(), set_peerdstadr() and
peer_refresh_interface().
>  it is also not clear that the multicast interface socket
> needs to be changed in the face of a local address change.
I know the answer for that one. If the local address of multicast
packets sent out changes and these packets are authenticated then you
must peer_clear(). I have tested correct operation in that case when the
dynamic interface code was developed. It was tested with a WAN address
being the default route changing. multicast/broadcast peers where
correctly following the address changes of the server.

Development in the last years may have changed things though (maybe
MDF_BCLNT is such a case) - it would probably be best to do a re-test here.
>  From the look
> of the code does not try to change the multicast interfaces if the local
> addresses changed.
>   
I think the code does that (see select_peerinterface()) - there is no
blocking of peer_clear() for MDF_MCAST marked peers. Where do you draw
your conclusion from ?

So the the next step should be to apply peer_clear() only to
cryptographic associations - that should be manageable.

Frank



More information about the hackers mailing list