[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