[ntp:questions] Re: Servers just doen't work (after following the troubleshooting page)
Danny Mayer
mayer at gis.net
Thu Sep 29 03:56:12 UTC 2005
David Schwartz wrote:
> "Per Hedeland" <per at hedeland.org> wrote in message
> news:dhdcoh$paq$1 at hedeland.org...
>
>
>>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
More information about the questions
mailing list