Danny Mayer wrote:
> It's probably not wise since if the connection is not up and ready, then
> you are just wasting the packets you send.
ALL IPs ARE STATIC!
the setup is:
<ntp server> ..<some inhouse routers/switches>..<ciscoA> ....<ISDN leased line>
...<ciscoB> ... <my
ntp client>
ciscoB log messages go to the ntp client machines syslog.
In a succesfull exchange I see 8 udp packets (calldelay15 + burst):
ReqC --> AnsS
..<15seconds delay>..
ReqC --> AnsS
..<~2sec>..
ReqC --> AnsS
..<~2sec>..
ReqC --> AnsS
In an UNsuccesfull exchange I see _1_ packet (calldelay15 + burst):
ReqC -->
<..76 seconds timeout, dialup taken down. >
> I suspect that the real problem is that the box is getting an IP address
> assigned by DHCP and you need to rebind the local address first so that
> the packet can go out from a valid address.
there is no IP change via DHCP or otherwise involved.
>
> Did NTP rebind the local address first?
NO address change involved.
>
> The protocol doesn't care. This is UDP. If it doesn't get a response it
> will try again later. When later is depends on the stage that it's at.
Right udp per se does not care.
what about ntpd:
at what moment in the exchange is the calldelay rundown started ?
imho it should be:
ReqC0----------------15sec>ReqC1
..AnsS0 ..AnsS1
my current guess is :
ReqC0->AnsS0----------------15sec>ReqC1
..AnsS1
I have looked into ntp_proto.c where this is handled
but am currently not through understanding the state stepping.
uwe
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
