Re: Servers just doen't work (after following the troubleshooting page)

David Schwartz wrote:
"Per Hedeland" <per@xxxxxxxxxxxx> wrote in message news:dhdcoh$paq$1@xxxxxxxxxxxxxxx


Hm, I assume that the bug you're referring to is the same as Danny
mentioned, that ntpd may/will respond with the wrong source address for
queries received on the wildcard socket (and actually I just now
verified that an old version of ntpd has that bug).


Right. And this is a Linux-specific bug, caused by the way NTP decides what interfaces to bind to *on* *Linux*.


That's actually an incorrect assessment. There is no Linux specific code in that area of the code. It does have to do with the way Linux responds to certain network function calls that used to result in it using the wildcard socket. This no longer happens in the recent releases of the development version. If it does it's a bug.


However the general theory of operation is that ntpd should bind a
socket to each individual address it is "supposed" to answer queries on
- then it can infer the destination address of the query (which isn't
available through the standard socket interface) based on which socket
the query is received on. I.e. if the address in question *is* bound to
a socket, the bug will not occur - and the OP claimed that ntpd *did*
have all the IP addresses bound (but I suspect he may be mistaken).

This is the way it now works in the newer development versions of the code. Older versions did not work correctly.


NTP should do whatever it has to do to get the same default behavior on every platform. It can offer platform-specific flags, where appropriate, to change the default behavior on platforms where things other than the default behavior might make sense.


It does. The response to calls to the O/S is dependent on the way that the O/S implemented the call. As a result you will have different reactions on different platforms. That is not an NTP problem (within limits).

It should not, for example, say "I won't bind to virtual interfaces on all platforms by default" for a false consistency if this results in different *behavior* on different OSes. The behavior should be the same, not the way it gets the behavior.


By default it binds to all interfaces, including the wildcard addresses. That's the way the code is written.


As to the -L flag, that's another of those unfortunate parameters that
have different meaning in different versions of ntpd - the official docs
say:

-L
  Do not listen to virtual IPs. The default is to listen.

- i.e. just the opposite of what the OP needs. However I know for a fact
that at least some versions shipped with RedHat (including the one the
OP is using) have a -L option that does mean the opposite of the above,
i.e. it is required for correct operation with secondary/virtual/alias
addresses.

That's the default. behavior. The -L will turn off the other IP addresses on every interface.

In short, your advice is probably right for the OP, but not 
universal.:-) I don't know whether this difference is due to changes in
the reference implementation or to special mods in the RedHat version.


We cannot be responsible for what Redhat or any other vendor does with the code.

Of course, but that's broken design. The effect of listening on "virtual IPs" or what constitues a virtual IP is a platform-specific thing. The flag should specify what NTP does, not how it does it. If it's going to be a platform-specific flag, it should be carefully arranged so that specifying *no* platform-specific flags gets you as close to the same behavior on all platforms.

The effect of -L is to listen on just the first IP address of the network hardware interface for each interface that it encounters. So if you have an eth0 and an eth1 interface it will use just the first address of eth0 and the first address of eth1. It will always use the loopback addresses, no matter what you specify.

It is NOT a platform-specific flag. If vendors use it for other purposes then we cannot do anything about that. You can always use the reference implementation can get what you need.

Danny
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

.

Relevant Pages

  • Re: Servers just doent work (after following the troubleshooting page)
    ... I assume that the bug you're referring to is the same as Danny ... > verified that an old version of ntpd has that bug). ... It can offer platform-specific flags, where appropriate, to ... change the default behavior on platforms where things other than the default ...
    (comp.protocols.time.ntp)
  • Re: Socket.Disconnect Method
    ... method that only worked on platforms prior to Windows ... method is supported on Windows 2000 and Windows 98, ... An error occurred when attempting to access the socket. ... It looks to me like the underlying error code could have been: ...
    (microsoft.public.vsnet.general)
  • Re: Odd routing problem
    ... >>socket gets closed by the system or by ntpd after $NUM errors. ... > did it) - but while it's one socket per interface, ... So it drops the socket but keeps on sending to the broadcast address ...
    (comp.unix.bsd.freebsd.misc)
  • Re: ntpd and network sockets
    ... it is unfortunate that both interface ... small" and then blythly ignore the socket entirely. ... that the stacks "socket buffer overflow" stat will increase I ... overflow in the ntpd itself. ...
    (comp.protocols.time.ntp)
  • Re: J with socket surfaces...
    ... After my recollection this is an early version platform with the Weitek socket physically still installed - but yet unsupported within the BIOS. ... They manufactured the first batches with the socket but removed the MPU support for the Weitek from the microcode since the 486DX, which was just available in larger quantities from Intel at that time, already has a MPU integrated. ... The BIOS has been replaced a few times during the active phase of these platforms. ...
    (comp.sys.ibm.ps2.hardware)