At 12:18 PM +0200 2005-08-13, Edrusb wrote:
Yes probably, it is too bad the same socket has not been used to send
data too, just leting the system put the appropriate Source IP and
select the adequate output interface according to system's routing
decision. This way there would not have any need to scan available
network interfaces for changes.
Nice theory, but it doesn't work that way in practice. Dig deep
into the code of programs like ntpd, BIND, and sendmail if you want
to understand why, but be prepared to spend a significant amount of
time learning about cross-platform issues, problems with IPv4 versus
IPv6, guaranteeing that reply packets always come from the same
interface and IP address that the query was sent to, and a whole host
of other problems.
It's just not that simple.
I have a "tap" interfaces that handles the traffic when the link is
down for dial on demand (see "diald" interesting and powerful
program), unfortunately, ntpd does not bind a socket to this
interface! Too bad.
Well, ntpd should bind to all interfaces that are up at the time
it starts, and remain bound to them until it is restarted. So, if
that tap interface works at all times, and remains consistent at all
times, you shouldn't have any problems.
I guess, the best solution waiting for next ntpd release, as described
by Steve Kostecke, is to have my local ntpd server for my local network
be "inside" the network without any dynamic IP address.
Either that, or stopping and restarting ntpd every time the
dynamic IP address changes.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
