[ntp:hackers] Cool new stuff
David L. Mills
mills at udel.edu
Mon Jul 24 03:17:32 UTC 2006
I see your point, but I really don't want to see a refclock address or
loopback address for that matter change, since lots and lots of bad
things would happen if they did. Is it the intended result of the scan
to bring up a new address when the ISP changes it? Doing so by default
is a serious security vunerability. The capability should not be
provided by default and the user should understand and accept the risk.
It would seem the scan interval, apparently fixed at a few minutes,
could be refined. It doesn't make sense to scan every few minutes if the
poll interval is 1024 seconds or even 36 hours. How about a
per-association configuration bit that operates only when the server
becomes unreacnable and does a scan initiated by the poll process?
As for the debug display, I am only concerned about the -d level.
Informally, I have used the -d -d level for things that happen once or
at relatively long intervals. The stuff at the -d -d -d level and above
are there only for emergencies and until the stuff is eventually removed.
Frank Kardel wrote:
> David L. Mills wrote:
>> This is profoundly and absolutely ridiculous.
> in your opinion it may be. It may not make much sense in general and
> especially not to you but
> configuration mechanisms in todays operating systems allow the
> reconfiguration and even the deletion
> of such interfaces (in NetBSD "lo?" is member of the cloning interface
> group - these interfaces can be created
> and destroyed as one wishes). Nobody of us can control what the vendor
> will do in his scripts or what a user would
> do. ntpd has to handle that and it does. The code does not even
> specifically scan for loopback interfaces - the
> interfaces just happen to show up in the interface list and all the
> code knows is how to manage a global
> variable "loopback_interface" that holds the loopback interface
> pointer (not the IP address but to the structure describing
> the address AND the socket file descriptor) that is assigned to
> refclock peers.
> I get the impression that your interpretation of "interface" is "IP
> address". My interpretation for
> "interface" is "the structure that holds the socket file descriptor
> bound to a specific IP address". So to discussion
> may have been on different abstraction levels.
>> The loopback interface and refclock interface addresses
> I was not talking about addresses - the code cares about sockets bound
> to (local) addresses. socket instances come
> and go. As do (local) addresses from the interfaces currently
> available to the system.
>> are not going to change. To do so would screw up links, the access
>> control list and who knows what else.
> no need to tell me that. the external addresses stay stable as
> configured. the local addresses may change as the
> interfaces in the system change. the acl for the local interface
> addresses are tracked with the changes.
> We need to differentiate between "leaf clients" that often have changing
> local IP addresses (WLAN, pppoe, "Zwangstrennung" and whatnot) and
> "servers" that have a stable address setup
> (how else could they be servers if they would constantly change their
> addresses). The dynamic interface code serves
> the purpose that ntpd's internal interface list stays in sync with
> reality and thus binds to all available interfaces all the time
> - one of ntpd design goals - and keeps up connectivity even when
> network setup is changing. On servers it would not see
> any changes - on "leaf clients" the code is likely to see frequent
>> In any case the excessive debug display screws up a per-minute
>> protocol watch. Lose the display
> that is not an option and you know that.
>> or move it up in the -d option.
> I am sorry that I messed up your debug display. Is is fixed now and
> Harlan pulled it into ntp-dev. If you want
> to see any significant output of network interaction wrt/ interfaces
> and addresses you need to specify debug levels of 3 and/or
> 4. Tell me if these levels still interfere with your debug display.
More information about the hackers