Denis Lagno wrote:

> I heared that new version of ntpd was imported which can track changes 
> in state of network interfaces.
>
> My access to internet is via ppp-connection via pptp.
> If I bring up ntpd after ppp interface is brought up, then all works 
> ok. If ppp connection falls and got reestablished then ntpd properly 
> switches to new address.
>
> However if ntpd is brought up before ppp-connection established then 
> it also works ok but it keeps trying every minute to access some 
> strange ipv6 address:
>
> Feb  1 01:39:33 flam ntpd[538]: ntpd 4.2.4-o Wed Jan 31 15:31:00 GMT 
> 2007 (1)
> Feb  1 01:39:33 flam ntpd[543]: precision = 3.911 usec
> Feb  1 01:39:33 flam ntpd[543]: ntp_io: estimated max descriptors: 64, 
> initial socket boundary: 20
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #0 wildcard, 
> 0.0.0.0#123 Disabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #1 wildcard, 
> ::#123 Disabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #2 ex0, 
> fe80::210:4bff:fe67:8727#123 Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #3 ex1, 
> 192.168.0.11#123 Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #4 ex1, 
> fe80::260:98ff:feef:e35d#123 Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #5 lo0, 
> 127.0.0.1#123 Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #6 lo0, ::1#123 
> Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on interface #7 lo0, 
> fe80::1#123 Enabled
> Feb  1 01:39:33 flam ntpd[543]: Listening on routing socket on fd #28 
> for interface updates
> Feb  1 01:39:33 flam ntpd[543]: kernel time sync status 2040
> Feb  1 01:39:33 flam ntpd[543]: frequency initialized 80.452 PPM from 
> /var/db/ntp.drift
> ..................
> Feb  1 01:40:40 flam dhclient: bound to 10.239.17.213 -- renewal in 
> 238810 seconds.
> Feb  1 01:40:44 flam pppd[1404]: pppd 2.4.4 started by root, uid 0
> ..................
> Feb  1 01:40:45 flam pppd[1404]: CHAP authentication succeeded
> Feb  1 01:40:45 flam pppd[1404]: local  IP address 89.178.98.106
> Feb  1 01:40:45 flam pppd[1404]: remote IP address 195.14.38.10
> Feb  1 01:40:47 flam ntpd[543]: Listening on interface #8 ex0, 
> 10.239.17.213#123 Enabled
> Feb  1 01:40:47 flam ntpd[543]: Listening on interface #9 ppp0, 
> 89.178.98.106#123 Enabled
> Feb  1 01:40:47 flam ntpd[543]: Listening on interface #10 ppp0, 
> fe80::210:4bff:fe67:8727#123 Enabled
> Feb  1 01:40:54 flam ntpd[543]: Cannot find existing interface for 
> address 2002:8ac3:802d:1243:204:e2ff:fe10:5c44
> Feb  1 01:40:54 flam ntpd_initres[845]: ntpd indicates no data available!
> Feb  1 01:41:45 flam pptp[780]: anon log[logecho:pptp_ctrl.c:676]: 
> Echo Reply received.
> Feb  1 01:41:53 flam ntpd[543]: Cannot find existing interface for 
> address 2002:8ac3:802d:1243:204:e2ff:fe10:5c44
> Feb  1 01:41:53 flam ntpd_initres[845]: ntpd indicates no data available!
> Feb  1 01:42:45 flam pptp[780]: anon log[logecho:pptp_ctrl.c:676]: 
> Echo Reply received.
> Feb  1 01:42:53 flam ntpd[543]: Cannot find existing interface for 
> address 2002:8ac3:802d:1243:204:e2ff:fe10:5c44
> Feb  1 01:42:53 flam ntpd_initres[845]: ntpd indicates no data available!
> Feb  1 01:43:45 flam pptp[780]: anon log[logecho:pptp_ctrl.c:676]: 
> Echo Reply received.
> Feb  1 01:43:53 flam ntpd[543]: Cannot find existing interface for 
> address 2002:8ac3:802d:1243:204:e2ff:fe10:5c44
> Feb  1 01:43:53 flam ntpd_initres[845]: ntpd indicates no data available!
> Feb  1 01:44:24 flam ntpd[543]: synchronized to 80.96.120.249, stratum 1
>
> And this "Cannot find existing interface for address 
> 2002:8ac3:802d:1243:204:e2ff:fe10:5c44" goes every minute.
>
> Is it a bug?

Not really, but annoying in the log. The reason is that when ntpd is 
started without any external inet connectivity
it will defer the resolution of domainnames to ip-addresses via 
ntpd_intres. Once the external net is accessible the resolution
succeeds but as you have no IPv6 link configuration ntpd_intres fails to 
configure the server/peer for the IPv6 address - that's
the log message.
If you want to configure IP addresses that are unreachable at 
configuration time you should add the keyword "dynamic" at
the end of the peer or server statement. This keyword instructs the 
configuration logic to configure the address even when
no usable local source interface can be found. Once the network 
configuration has changed sufficiently to reach that address servers/peers
configured that way will start to work.
So use the dynamic keyword when attempting to configure peers/servers 
before having the actual network configuration available.
This way you can configure ntp servers/peers statically before any 
external network connectivity exists.

>
> -- denis

Frank