[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: ntpd listening on alias interfaces seems non-trivial




Excuse my reply to an 11 month old thread in googles top 30 on this subject. No solution was posted in that thread, here is one I've just tested and it works for me.

I guess NTPD simply receives the packet on the 0.0.0.0:123 socket and the source address is set by way of the interface address after routing has been worked out. It would probably be undesirable to have NTPD to see and bind to each aliases interface, maybe NTPD should allow an 'interface [ifname|ipaddr]' that will at a minimum create a 'restrict' rule with the 'interface' flag set, this could allow for automatic re-binding to unavailable interfaces at the time NTPD was started.

My solutions creates a dummy network interface that give NTPD a real interface to see and bind to, this only problem with this is that if the real ethernet based interface is downed (administrative or disabled) then the local host will still be able to route to that IP, unless you remembered to down dummy0 too.


$ /etc/init.d/ntpd stop
$ modprobe dummy
$ ifconfig dummy0 <the_ip_I_wanted_thats_aliased>
$ /etc/init.d/ntpd start


$ ntpdc
ntpdc> reslist
  address          mask            count        flags
=====================================================================
<the_ip_I_wanted_thats_aliased> 255.255.255.255 0 ntpport, interface, ignore
ntpdc> [Ctrl-D]

$ netstat -uan | grep 123
udp        0      0 <the_ip_I_wanted_thats_aliased>:123       0.0.0.0:*


Maybe this will be of use to someone else or someone has a better solution.


On Sun, 2004-01-18 at 23:31, Marius Olsthoorn wrote:
Ntp uses its own protocol on top of UDP. Each ntp packet includes source
and destination addresses of the communication. The ntpd server uses this
data and checks if a answer came from the same host the request was sent
to. If this is not the case, it assumes something is wrong.

Whatever the technical reasons, ntp is not happy if the response comes
from a different IP to the one the request was sent to (this doesn't
require IP's in the packet... the client could be just checking the
src/dest IP's match).



--
Darryl L. Miles




Reply to: