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). > In your setup clients connect to one ip(of the alias) and you send the > reply via your main interface. These ip's then don't match. I don't think > it is possible to use alias interfaces with ntpd. If you do get it running > somehow please let me know. The problem is ntpd doesn't respond on the same interface it receives a request on. It responds on the default interface routed to the querying client. I believe there are bug reports on this; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209054 I did see a post that claims this was fixed in one of the latest RH packages, but I'm yet to see confirmation that this is true. > > I have been attempting, without success, to get ntpd listening on an alias > > interface on one of my general purpose boxes. It seems that ntpd prefers to > > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as > > well, but does not respond to queries on other addresses. Here is some LSOF > > output demonstrating this..: > > > > # lsof -p 16667 |grep UDP > > ntpd 16667 root 4u IPv4 4493134 UDP *:ntp > > ntpd 16667 root 5u IPv4 4493135 UDP localhost:ntp > > ntpd 16667 root 6u IPv4 4493136 UDP hostname:ntp > > > > I checked the archives, and it seems another poster had similar trouble in > > Dec'02, but there were no apparent follow-up posts. Google has also been > > less than revealing on this topic. All suggestions entertained. The only workaround I know of is to route the ntp responses explicitly via the alias. You can use iproute2 to try and route only ntp responses via this alias, but it is non-trivial as iproute2 rules don't allow port based rule selection. Another possibility is to use NAT to re-map the response on the way out... once again, if anyone gets this working, please post how you did it. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
