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

Danny Mayer mayer at ntp.org
Fri Nov 27 13:45:49 UTC 2009


Frank Kardel wrote:
> 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.

I remember the discussion with Dave. However, if neither remote nor
local address has changed you don't need to reset the association.

>>  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 ?

Not right now unless I still have the binary and I think that there was
an incompatible change that prevented it from working with mort which is
the broadcasting server.

>>  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.

Why would we do that for only one type of association?

>>  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.

Agreed, so if nothing changed why reset the association in case the
routing might have changed?

>>  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.

Agreed but you only need to do that if the address changed.

>> 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.
>

Me roo but the logs I got aren't useful because the timestamping of the
debug output when sent to syslog got dropped when in debug mode. That
was an annoying and unexpected change.

> 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().

No, you really need to consider all types especially as dynamically
allocated client may have moved sites and is now no longer getting
broadcast packets from server A and is not getting them from server B
instead and server A broadcast packets is no longer being received on
the new LAN or wireless segment.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the hackers mailing list