Re: [ntp:questions] Multicast and dynamic interfaces
barry bouwsma wrote: Moin, ntp-dev-4.2.5p118, Linux latest-ish. Also observed with ntp-dev-4.2.5p113 Should ntpd be able to listen for multicasts on interfaces that get added/configured after ntpd starts? For example, I just brought up and configured this interface: Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #9 eth3, 172.27.72.99#123 Enabled However I'm not able to get it to hear the multicast data which can be heard, no matter how long I wait, unless I restart ntpd, like so: Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #3 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #5 eth3, 172.27.72.99#123 Enabled Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #6 multicast, 224.0.1.1#123 Enabled Jul 9 21:15:43 localhost ntpd[19791]: setsockopt IP_ADD_MEMBERSHIP failure: No Jul 9 21:15:43 localhost ntpd[19791]: Failed to add Multicast Listener 224.0.1.1 (no big deal that) Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #7 multicast, ff05::101#123 Enabled Jul 9 21:15:43 localhost ntpd[19791]: Added Multicast Listener ff05::101 on interface #7 multicast And voila, now I can hear and use that multicast data... remote refid st t when poll reach delay offset jitter == fe80::200:c0ff: .DCFa. 1 m 14 16 2000.7411.240 0.008 Is this a case of missing or non-functioning code, or is this something that really isn't possible? It sounds like a bug, possibly 2 bugs. Please file a bug report. The multicast option should reconfigure itself after a change of IP address and rebind itself to the new address. If the address has gone away then the multicast socket won't be able to receive any multicast packets. Are you using DHCP provided addresses or static ones? Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .INIT. oddity
Tuc at T-B-O-H.NET wrote:
Hi,
Having an issue and its really perplexing. Its a bit of a read,
so maybe you'll want to go for a dinner break first...
The story starts out with a FreeBSD 4.X system (Its my personal
server, I've been lazy to upgrade it, I know, I know, I know) running
4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
server GOOD_SERVER1
server GOOD_SERVER2
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 0.ca.pool.ntp.org
server 0.mx.pool.ntp.org
I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
again, I'm required to run that version currently). Both of them are
running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
When the story started, I saw the following in an ntpq{peers} :
remote refid st t when poll reach delay offset jitter
==
GOOD_SERVER1.INIT. 16 u- 6400.0000.000 0.000
GOOD_SERVER2.INIT. 16 u- 6400.0000.000 0.000
+ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
+clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
+lashiir.sapros. 74.53.198.1463 u 572 1024 377 44.344 -45.981 0.023
*raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
-cronos.cenam.mx .GPS.1 u 504 1024 377 236.263 31.443 130.461
I wasn't sure why it wasn't syncing to servers 3 feet away from it,
on the same router (different subnet, but there is perfect connectivity
between
the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
so I pulled an M$ and restarted ntp. No dice. I ran ntpdates to both of them
perfectly, no issues, etc. I even used a web page that ran against them and
came back with sane looking info. tcpdumps seemed to show the request went
out,
got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
So I then tried the typical thing of upgrading BAD_SYSTEM to
[EMAIL PROTECTED] . Same thing.
I then upgraded GOOD_SERVER2 to [EMAIL PROTECTED] . Same thing.
harlan on IRC had me do peer instead of server.
BEFORE GOOD_SERVER2 WAS UPGRADED:
BAD_SYSTEM: .INIT.
GOOD_SERVER2: .DROP.
AFTER GOOD_SERVER2 WAS UPGRADED:
BAD_SYSTEM: .INIT.
GOOD_SERVER2: showed valid information
I wouldn't recommend trying to use peer here. What's in the
good_server's ntp.conf file. Do you have any restrict options? Did you
put in the fully-qualified domain name (FQDN) of the good server in the
ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
dig +search to check this. Are there any errors in the log?
If all of this checks out start running tcpdump and make sure the
packets are going out and on the other side, coming in.
Danny
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Multicast and dynamic interfaces
Sorry for line-mangling... --- On Fri, 7/11/08, Danny Mayer [EMAIL PROTECTED] wrote: Should ntpd be able to listen for multicasts on interfaces that get added/configured after ntpd starts? For example, I just brought up and configured this interface: Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #9 eth3, 172.27.72.99#123 Enabled Is this a case of missing or non-functioning code, or is this something that really isn't possible? It sounds like a bug, possibly 2 bugs. Please file a bug report. The multicast option should reconfigure itself after a change of IP address and rebind itself to the new address. If the address has gone away then the multicast socket won't be able to receive any multicast packets. Are you using DHCP provided addresses or static ones? This is a case of connecting after boot a USB ethernet adapter and manually assigning an IP address based on to which net I'm attaching myself and with which machines I wish to speak (though that shouldn't matter for multicast). I've also seen the same when I've manually reconfigured a WLAN interface to associate with a different network, over which I broadcast the name quoted multicast that I'm trying to hear via the USB adapter above. The IPv6 multicast seems to require no user intervention, either thanks to, in my case, the Linux kernel, or something else, while I have to set the route to 224.x.x.x in order for IPv4 multicast to be received. In the example I posted, I had failed to set that route before restarting ntpd, while the IPv6 m'cast was heard loud and clear, and the needed handshake took place. I start ntpd at boot; network configuration takes place later (WLAN depending on to which network I wish to associate, not all of which have NTP m'casts) by hand, though I've a template at boot that sets most ifconfig needed for IP address and such (interface doesn't go RUNNING until I actually associate with a particular WLAN). Hmm, maybe I need to test if the WLAN interface, which has the IPv6 ff00::/8 route on it, can pick up m'cast after switching WLANs... Nope, didn't help thanks, barry bouwsma ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .INIT. oddity
Tuc at T-B-O-H.NET wrote:
Hi,
Having an issue and its really perplexing. Its a bit of a read,
so maybe you'll want to go for a dinner break first...
The story starts out with a FreeBSD 4.X system (Its my personal
server, I've been lazy to upgrade it, I know, I know, I know) running
4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
server GOOD_SERVER1
server GOOD_SERVER2
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 0.ca.pool.ntp.org
server 0.mx.pool.ntp.org
I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
again, I'm required to run that version currently). Both of them are
running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
When the story started, I saw the following in an ntpq{peers} :
remote refid st t when poll reach delay offset
jitter
==
GOOD_SERVER1.INIT. 16 u- 6400.0000.000
0.000
GOOD_SERVER2.INIT. 16 u- 6400.0000.000
0.000
+ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986
2.191
+clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933
0.219
+lashiir.sapros. 74.53.198.1463 u 572 1024 377 44.344 -45.981
0.023
*raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695
3.159
-cronos.cenam.mx .GPS.1 u 504 1024 377 236.263 31.443
130.461
I wasn't sure why it wasn't syncing to servers 3 feet away from it,
on the same router (different subnet, but there is perfect connectivity
between
the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS,
etc)
so I pulled an M$ and restarted ntp. No dice. I ran ntpdates to both of
them
perfectly, no issues, etc. I even used a web page that ran against them and
came back with sane looking info. tcpdumps seemed to show the request went
out,
got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
So I then tried the typical thing of upgrading BAD_SYSTEM to
[EMAIL PROTECTED] . Same thing.
I then upgraded GOOD_SERVER2 to [EMAIL PROTECTED] . Same thing.
harlan on IRC had me do peer instead of server.
BEFORE GOOD_SERVER2 WAS UPGRADED:
BAD_SYSTEM: .INIT.
GOOD_SERVER2: .DROP.
AFTER GOOD_SERVER2 WAS UPGRADED:
BAD_SYSTEM: .INIT.
GOOD_SERVER2: showed valid information
I wouldn't recommend trying to use peer here. What's in the
good_server's ntp.conf file. Do you have any restrict options? Did you
put in the fully-qualified domain name (FQDN) of the good server in the
ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
dig +search to check this. Are there any errors in the log?
If all of this checks out start running tcpdump and make sure the
packets are going out and on the other side, coming in.
Sorry I realized I forgot GOOD_SERVER1+2's ntp.conf. They both are:
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 0.ca.pool.ntp.org
server 0.mx.pool.ntp.org
No, no restrict. Yes, FQDN. Yes, name resolves to an A record, but
the forward/backward don't match. (I'm referencing GOOD_SERVER1 as
ntp1.example.com,
but its in-addr.arpa is v.example.com . GOOD_SERVER2 as ntp2.example.com, but
its in-addr.arpa is a.example.com . ) I've got the same ntp.conf on BAD_SERVER
as every OTHER server in the datacenter, and none of the others have the
slightest
problem. dig +search shows an IN A of the proper IP. No errors in the logs.
Yup, they do. I can track the packets back and forth on both systems.
Tuc/TBOH
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] drift modeling question
Has anyone thought about removing both the linear terms and quadratic terms in the drift, by utilizing the temperature sensor readings available on many of the latest motherboards? Crystal oscillators tend to have both a linear bias and a quadratic bias, determinate upon temperature, leaving a stochastic component, which I believe we're trying to compensate for all along by the operation of ntp. Integration of the temperature readings and knowledge of the current drift should suggest the appropriate coefficients for the corrections. Just a thought, but it seems a shame that we're not taking advantage of the thermal data available to us, when correcting for clock drift and simply using a linear correction. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift modeling question
In article [EMAIL PROTECTED], shy author [EMAIL PROTECTED] writes: Has anyone thought about removing both the linear terms and quadratic terms in the drift, by utilizing the temperature sensor readings available on many of the latest motherboards? Linear works pretty well. I think it would be hard to get quadratic. NTP temperature compensation Mark Martinec, 2001-01-08 http://www.ijs.si/time/temp-compensation/ Just a thought, but it seems a shame that we're not taking advantage of the thermal data available to us, when correcting for clock drift and simply using a linear correction. The temperature sensor is probably in the CPU chip. You probably want it on the crystal. The sensors on CPUs tend to be coarse. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift modeling question
shy author [EMAIL PROTECTED] writes: Has anyone thought about removing both the linear terms and quadratic terms in the drift, by utilizing the temperature sensor readings available on many of the latest motherboards? Crystal oscillators tend to have both a linear bias and a quadratic bias, determinate upon temperature, leaving a stochastic component, which I believe we're trying to compensate for all along by the operation of ntp. Integration of the temperature readings and knowledge of the current drift should suggest the appropriate coefficients for the corrections. Just a thought, but it seems a shame that we're not taking advantage of the thermal data available to us, when correcting for clock drift and simply using a linear correction. A Quadratic correction tends to run away pretty badly if you suddenly have a period of no ntp readings. But I am not at all sure that is what you mean. Rather you seem to mean that one use the temp to estimate what the linear drift is ( from the past readings of temp and drift.) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntpdate with auth
Hi all, Have anybody tried using ntpdate with iff and rsa keys on the time server ? There is no problem when using symmetric md5 keys (-k and -a options for ntpdate) but i have no idea how to force ntpdate to use the public key for iff when remote server uses only that type of authentication. Ntpd works perfect with that but unfortunately not ntpdate. thanks for your help, Grzegorz Daniluk ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
