Hi All,
I am trying to get ntp to sync with an ntp server without much luck on FC2.
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
My FC2 system time is set within one minute of two other servers I have using ntp; one RH7.3 and another FC1.
I've set the FC2 time by hand. When I start ntp I see the following message in my /var/log/messages log.
Sep 19 22:12:29 www ntpd[3183]: ntpd 4.2.0@1.1161-r Thu Mar 11 11:46:39 EST 2004 (1) Sep 19 22:12:29 www ntpd[3183]: precision = 1.000 usec Sep 19 22:12:29 www ntpd: ntpd startup succeeded Sep 19 22:12:29 www ntpd[3183]: no IPv6 interfaces found Sep 19 22:12:29 www ntpd[3183]: kernel time sync status 0040 Sep 19 22:12:30 www ntpd[3183]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Any insight appreciated!
Mike
On 2004 09 20 (Monday) 08:18, Mike McMullen wrote:
Hi All,
I am trying to get ntp to sync with an ntp server without much luck on FC2.
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
My FC2 system time is set within one minute of two other servers I have using ntp; one RH7.3 and another FC1.
I've set the FC2 time by hand. When I start ntp I see the following message in my /var/log/messages log.
Sep 19 22:12:29 www ntpd[3183]: ntpd 4.2.0@1.1161-r Thu Mar 11 11:46:39 EST 2004 (1) Sep 19 22:12:29 www ntpd[3183]: precision = 1.000 usec Sep 19 22:12:29 www ntpd: ntpd startup succeeded Sep 19 22:12:29 www ntpd[3183]: no IPv6 interfaces found Sep 19 22:12:29 www ntpd[3183]: kernel time sync status 0040 Sep 19 22:12:30 www ntpd[3183]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Any insight appreciated!
Mike
Try this ntp.conf: --- cut --- # Prohibit general access to this service. restrict default ignore # Permit all access over the loopback interface. restrict 127.0.0.1 # -- CLIENT NETWORK ------- # restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap # --- OUR TIMESERVERS ----- server SERVER(s).IP.ADDR.HERE restrict SERVER(s).IP.ADDR.HERE mask 255.255.255.255 nomodify notrap noquery
# --- GENERAL CONFIGURATION --- # Undisciplined Local Clock. server 127.127.1.0 fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift broadcastdelay 0.008 #authenticate yes #keys /etc/ntp/keys --- cut --- And add one/some of the NTP servers you'll use in /etc/ntp/step-tickers. These are used to synchronize at ntp start (with ntpdate by the rc script).
Mike McMullen wrote:
Hi All,
I am trying to get ntp to sync with an ntp server without much luck on FC2.
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
My FC2 system time is set within one minute of two other servers I have using ntp; one RH7.3 and another FC1.
I've set the FC2 time by hand. When I start ntp I see the following message in my /var/log/messages log.
Sep 19 22:12:29 www ntpd[3183]: ntpd 4.2.0@1.1161-r Thu Mar 11 11:46:39 EST 2004 (1) Sep 19 22:12:29 www ntpd[3183]: precision = 1.000 usec Sep 19 22:12:29 www ntpd: ntpd startup succeeded Sep 19 22:12:29 www ntpd[3183]: no IPv6 interfaces found Sep 19 22:12:29 www ntpd[3183]: kernel time sync status 0040 Sep 19 22:12:30 www ntpd[3183]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Any insight appreciated!
Mike
If you continue to have trouble, show us the output of ntpq -p as a starter.
----- Original Message ----- From: "John DeDourek" dedourek@unb.ca To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Monday, September 20, 2004 6:11 AM Subject: Re: NTP syncing
If you continue to have trouble, show us the output of ntpq -p as a starter.
Hi John,
This is the output I see for ntpq -p:
remote refid st t when poll reach delay offset jitter ============================================================================== ns.arc.nasa.gov .INIT. 16 - - 1024 0 0.000 0.000 4000.00 ntp0.usno.navy. .INIT. 16 - - 1024 0 0.000 0.000 4000.00
Thanks,
Mike
Mike McMullen wrote:
This is the output I see for ntpq -p:
remote refid st t when poll reach delay offset jitter============================================================================== ns.arc.nasa.gov .INIT. 16 - - 1024 0 0.000 0.000 4000.00 ntp0.usno.navy. .INIT. 16 - - 1024 0 0.000 0.000 4000.00
So your server is unable to communicate with your chosen NTP servers.
Do you have firewall rules that might be blocking NTP traffic?
What "restrict" lines do you have in your ntp.conf file?
Paul.
----- Original Message ----- From: "Paul Howarth" paul@city-fan.org To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Monday, September 20, 2004 6:39 AM Subject: Re: NTP syncing
Mike McMullen wrote:
This is the output I see for ntpq -p:
remote refid st t when poll reach delay offset jitter============================================================================== ns.arc.nasa.gov .INIT. 16 - - 1024 0 0.000 0.000 4000.00 ntp0.usno.navy. .INIT. 16 - - 1024 0 0.000 0.000 4000.00
So your server is unable to communicate with your chosen NTP servers.
Do you have firewall rules that might be blocking NTP traffic?
What "restrict" lines do you have in your ntp.conf file?
Hi Paul,
Here is the contents of my ntp.conf file:
# Prohibit general access to this service. restrict default ignore #restrict 66.187.233.4 mask 255.255.255.255 nomodify notrap noquery
# Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1
# -- CLIENT NETWORK ------- # Permit systems on this network to synchronize with this # time service. Do not permit those systems to modify the # configuration of this service. Also, do not use those # systems as peers for synchronization. # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
# --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system.
# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip
# --- NTP MULTICASTCLIENT --- #multicastclient # listen on default 224.0.1.1 # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
# --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. #
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
#server 66.187.233.4 fudge 127.127.1.0 stratum 10
# # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /var/lib/ntp/drift broadcastdelay 0.008
# # Authentication delay. If you use, or plan to use someday, the # authentication facility you should make the programs in the auth_stuff # directory and figure out what this number should be on your machine. # #authenticate yes
# # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. Note also that # ntpd is started with a -A flag, disabling authentication, that # will have to be removed as well. # keys /etc/ntp/keys
Mike McMullen wrote:
Here is the contents of my ntp.conf file:
# Prohibit general access to this service. restrict default ignore #restrict 66.187.233.4 mask 255.255.255.255 nomodify notrap noquery
# Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1
...
# --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system.
# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip
You need to add lines here:
restrict time.nist.gov mask 255.255.255.255 nomodify notrap noquery restrict ns.arc.nasa.gov mask 255.255.255.255 nomodify notrap noquery restrict tick.usno.navy.mil mask 255.255.255.255 nomodify notrap noquery
...
# --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. #
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
#server 66.187.233.4
Wasn't there a line:
server 127.127.1.0 # local clock
here originally?
fudge 127.127.1.0 stratum 10
Cheers, Paul.
You are obviously missing the restrict lines for your selected servers, replace $ipOfServer and add the following line for each server entry:
restrict $ipOfServer mask 255.255.255.255 nomodify notrap noquery
Tom
----- Original Message ----- From: "Paul Howarth" paul@city-fan.org To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Monday, September 20, 2004 7:12 AM Subject: Re: NTP syncing
Wasn't there a line:
server 127.127.1.0 # local clock
Hi Paul,
If that line was there it must have been deleted accidentally.
I made the changes you suggested and when I do an ntpq -p I get the following:
remote refid st t when poll reach delay offset jitter ============================================================================== time.nist.gov .ACTS. 1 u 43 64 1 43.295 4812.14 0.002 ns.arc.nasa.gov 198.123.30.132 2 u 47 64 1 22.387 4812.17 0.002 tick.usno.navy. .USNO. 1 u 46 64 1 272.895 4894.98 0.002 LOCAL(0) LOCAL(0) 10 l 45 64 1 0.000 0.000 0.002
This is more than I got before. The time now seems to be within 3-4 seconds of my other servers.
When I do ntpstat though I get the following:
unsynchronised time server re-starting polling server every 16 s
So I seem to be very close.
Mike
Mike McMullen wrote:
I made the changes you suggested and when I do an ntpq -p I get the following:
remote refid st t when poll reach delay offset jitter============================================================================== time.nist.gov .ACTS. 1 u 43 64 1 43.295 4812.14 0.002 ns.arc.nasa.gov 198.123.30.132 2 u 47 64 1 22.387 4812.17 0.002 tick.usno.navy. .USNO. 1 u 46 64 1 272.895 4894.98 0.002 LOCAL(0) LOCAL(0) 10 l 45 64 1 0.000 0.000 0.002
This is more than I got before. The time now seems to be within 3-4 seconds of my other servers.
When I do ntpstat though I get the following:
unsynchronised time server re-starting polling server every 16 s
So I seem to be very close.
It takes a while to synchronise properly. Give it time.
Your time would be closer to real time if you ran ntpdate before starting up ntpd though. If you create/edit the file /etc/ntp/step-tickers and have it contain the following lines:
time.nist.gov ns.arc.nasa.gov tick.usno.navy.mil
then the Fedora NTP initscript will try to synchronise time with one of those servers before starting ntpd, and your time will be better synchronised, more quickly.
Cheers, Paul.
----- Original Message ----- From: "Paul Howarth" paul@city-fan.org To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Monday, September 20, 2004 7:47 AM Subject: Re: NTP syncing
So I seem to be very close.
It takes a while to synchronise properly. Give it time.
Your time would be closer to real time if you ran ntpdate before starting up ntpd though. If you create/edit the file /etc/ntp/step-tickers and have it contain the following lines:
time.nist.gov ns.arc.nasa.gov tick.usno.navy.mil
then the Fedora NTP initscript will try to synchronise time with one of those servers before starting ntpd, and your time will be better synchronised, more quickly.
Cheers, Paul.
Hi Paul,
Looks like it is working. I got the following output from ntpstat:
synchronised to local net at stratum 11 time correct to within 12 ms polling server every 64 s
Thanks for the advice on ntpdate. I've added that info to /etc/ntp/step-tickers.
I really appreciate your taking the time to help me here.
Thanks!
Mike
On Mon, 2004-09-20 at 09:34, Mike McMullen wrote:
When I do ntpstat though I get the following:
unsynchronised time server re-starting polling server every 16 s
So I seem to be very close.
Don't let it go on for days...use "rdate -s time.nist.gov" to set it once, then let NTP slip it back and forth to keep it accurate.
Paul Howarth wrote:
Mike McMullen wrote:
....
Wasn't there a line:
server 127.127.1.0 # local clock
here originally?
fudge 127.127.1.0 stratum 10
Cheers, Paul.
Note that is a "stupidity" of the Fedora install. When you specify an ntp server during the install, I conclude by observation that it -->replaces<-- the server 127.127.1.0 # local clock by server ...whatever server you specify during install YMMV
There's also another thread about some strangeness in the interaction between the ntp configuration and the iptables configuration during a standard install.
I should pursue this, but am fighting another battle right now and it doesn't directly affect me because I run both a very custom ntpd configuration and a very custom iptables install.
John
Paul Howarth wrote:
Your time would be closer to real time if you ran ntpdate before starting up ntpd though. If you create/edit the file /etc/ntp/step-tickers and have it contain the following lines:
Actually, the ntp people are trying to deprecate ntpdate. They have an option to ntpd that essentially tells it to do the sort of equivalent of ntpdate when it starts...(I forget -g, or -q, or something). In any case I believe that the Fedora /etc/rc.d/init.d/ntpd does the "right thing" and uses the "step tickers" file if it exists and is non-null to call ntpdate and starts ntpd; or if you make that file null, I think it starts ntpd in the "do an initial jump" mode. I would need to investigate further to absolutely confirm this though. (Redhat 7.3 ran that way, but they did a bunch of changes to the ntpd script for Fedora.)
John
On Sun, Sep 19, 2004 at 10:18:53PM -0700, Mike McMullen wrote:
Hi All,
I am trying to get ntp to sync with an ntp server without much luck on FC2.
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
It seems nifty to try and sync to such famous quality sites but they are busy and overloaded. You can get better time from other places simply because cliend load is less.
It is better to select a modest set of tier 2 sites that are published at the ntp.org home page
http://www.eecis.udel.edu/~mills/ntp/servers.html http://www.eecis.udel.edu/~mills/ntp/clock2b.html
I found that it is good to build a list of ten then comment out all but three.
There is an interesting project, pool.ntp. Read about it. I recommend that you comment out your servers from the .gov and .mil and add these.
# http://www.pool.ntp.org/ server pool.ntp.org server pool.ntp.org server pool.ntp.org
The abuse of famous public time reference sites is causing changes and many requiring the exchange of passwd/keys.
If you have friendly administrators at near by companies you should exchange services, keys and contact information.
Ask your ISP for a ntp reference list. This is a service that all ISP's should be providing (IMO).
--On Monday, September 20, 2004 10:38 PM -0700 Nifty Hat Mitch mitch48@sbcglobal.net wrote:
Ask your ISP for a ntp reference list. This is a service that all ISP's should be providing (IMO).
Many ISP's supply NTP on their DNS servers or their routers, but it sometimes takes a bit of digging to find someone who'll own up to its being there. Ideally the NTP server should be supplied by DHCP and it should an appropriate DNS name (eg. ntp.myisp.com), but few ISP's do this.
From: "Kenneth Porter" shiva@sewingwitch.com
--On Monday, September 20, 2004 10:38 PM -0700 Nifty Hat Mitch mitch48@sbcglobal.net wrote:
Ask your ISP for a ntp reference list. This is a service that all ISP's should be providing (IMO).
Many ISP's supply NTP on their DNS servers or their routers, but it sometimes takes a bit of digging to find someone who'll own up to its
being
there. Ideally the NTP server should be supplied by DHCP and it should an appropriate DNS name (eg. ntp.myisp.com), but few ISP's do this.
I noticed this ages ago. I also noticed that their time bore only a hazy relationship to the clocks at UCSD. UCLA, and others. GTEI's ntp was worst of the bunch. But then, I've not looked recently. So ymmv.
{^_^}
--On Monday, September 20, 2004 11:03 PM -0700 jdow jdow@earthlink.net wrote:
I noticed this ages ago. I also noticed that their time bore only a hazy relationship to the clocks at UCSD. UCLA, and others. GTEI's ntp was worst of the bunch. But then, I've not looked recently. So ymmv.
One should test them with ntptrace to verify their quality.
Hi Paul,
Looks like it is working. I got the following output from ntpstat:
synchronised to local net at stratum 11 time correct to within 12 ms polling server every 64 s
Thanks for the advice on ntpdate. I've added that info to /etc/ntp/step-tickers.
I really appreciate your taking the time to help me here.
Thanks!
Mike
That means you are sync'd with your hardware clock which by default is stratum 10 on Fedora.
It takes a little longer to sync with the other servers. But the thing is you are syncing to stratum 1 servers to be stratum 2 yourself. You don't need to do that and only add more bandwidth to something that is going to only give you a few more miliseconds of accuracy. Sync to stratum 2 or higher if that is only a local ntp server.
I usually sync to a ntp pool if I have to sync a desktop to something over the net. (or past my ISP) http://www.pool.ntp.org/
I suggest doing the same. (and everybody else I saw with tick and tock on their ntp conf files) It is a rare occourance that you need that much accuracy.
- Michael
On Mon, Sep 20, 2004 at 11:03:48PM -0700, jdow wrote:
From: "jdow" jdow@earthlink.net To: "For users of Fedora Core releases" fedora-list@redhat.com Date: Mon, 20 Sep 2004 23:03:48 -0700 Subject: Re: NTP syncing Reply-To: For users of Fedora Core releases fedora-list@redhat.com
From: "Kenneth Porter" shiva@sewingwitch.com
--On Monday, September 20, 2004 10:38 PM -0700 Nifty Hat Mitch mitch48@sbcglobal.net wrote:
Ask your ISP for a ntp reference list. This is a service that all ISP's should be providing (IMO).
Many ISP's supply NTP on their DNS servers or their routers, but it sometimes takes a bit of digging to find someone who'll own up to its
being
there. Ideally the NTP server should be supplied by DHCP and it should an appropriate DNS name (eg. ntp.myisp.com), but few ISP's do this.
I noticed this ages ago. I also noticed that their time bore only a hazy relationship to the clocks at UCSD. UCLA, and others. GTEI's ntp was worst of the bunch. But then, I've not looked recently. So ymmv.
What is it that they say on one of the TV cop shows.
"Trust but verify".
For folks that manage 'business' sites "good time" is not a party it is a business requirement. More to the point "good time" shared with business partners is important.
If my company and your company exchange items worth money it makes sense that both of us have some clue about the quality of time. By meshing "ntp" time references it is possible share time related bandwidth and also know with 'trace' that time is synchronized.
On Tuesday 21 September 2004 01:38, Nifty Hat Mitch wrote:
On Sun, Sep 19, 2004 at 10:18:53PM -0700, Mike McMullen wrote:
Hi All,
I am trying to get ntp to sync with an ntp server without much luck on FC2.
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
It seems nifty to try and sync to such famous quality sites but they are busy and overloaded. You can get better time from other places simply because cliend load is less.
It is better to select a modest set of tier 2 sites that are published at the ntp.org home page
http://www.eecis.udel.edu/~mills/ntp/servers.html http://www.eecis.udel.edu/~mills/ntp/clock2b.html
I found that it is good to build a list of ten then comment out all but three.
I don't recall where I got it from, but I have a script that chooses 4 from a random list of about 38 servers. If nothing else, the random choice should reduce the average load on any one if everyone used such a scheme. But this was a nice link, I'm going to remove tick and tock because they time out quite often, and add some from the above stratum 2 list.
There is an interesting project, pool.ntp. Read about it. I recommend that you comment out your servers from the .gov and .mil and add these.
# http://www.pool.ntp.org/ server pool.ntp.org server pool.ntp.org server pool.ntp.org
The abuse of famous public time reference sites is causing changes and many requiring the exchange of passwd/keys.
I've wondered how long they can keep it up.
If you have friendly administrators at near by companies you should exchange services, keys and contact information.
Ask your ISP for a ntp reference list. This is a service that all ISP's should be providing (IMO).
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
-- T o m M i t c h e l l In the USA, vote informed, second Tuesday Nov 2004.
Amen
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett gene.heskett@verizon.net wrote:
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
According to http://www.dslreports.com/faq/5825 Verizon has monitored support newsgroups. There's also some Verizon forums at http://www.dslreports.com/forums/47.
Try running ntptrace to your Verizon-supplied DNS servers and to your gateway. One of them may have decent time.
On Mon, 2004-09-20 at 23:48, Kenneth Porter wrote:
Many ISP's supply NTP on their DNS servers or their routers, but it sometimes takes a bit of digging to find someone who'll own up to its being there. Ideally the NTP server should be supplied by DHCP and it should an appropriate DNS name (eg. ntp.myisp.com), but few ISP's do this.
When I set up a gateway/firewall on Fedora I always set up and configure NTP properly. Since I have six or seven of these boxen and one public web server, each NTP service is configured to use one other firewall box, the public webserver, and a stratum 2 server as time sources. That way I generate lower load on everyone else.
I'll also offer up all my servers to the pool.ntp.org project, as well. I think it's a great idea, quintessentially representative of the Linux community, and one which many of us should support. See www.pool.ntp.org for more information.
On Mon, 2004-09-20 at 23:48, Kenneth Porter wrote:
Many ISP's supply NTP on their DNS servers or their routers, but it sometimes takes a bit of digging to find someone who'll own up to its being there. Ideally the NTP server should be supplied by DHCP and it should an appropriate DNS name (eg. ntp.myisp.com), but few ISP's do this.
By the way, all my DHCP servers provide a pointer to my NTP servers. How do I get clients (Fedora Linux and Windows) to use this pointer? Anyone have any idea? Can't find docs to tell me.
Cheers,
On Sun, 2004-09-19 at 23:18, Mike McMullen wrote:
I have the following servers defined in /etc/ntp.conf
server time.nist.gov prefer server ns.arc.nasa.gov prefer server tick.usno.navy.mil prefer
Since it has not been mentioned before, I'll comment that only *one* server should have the prefer keyword.
Cheers,
On Tue, Sep 21, 2004 at 10:34:23PM -0700, Kenneth Porter wrote:
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
According to http://www.dslreports.com/faq/5825 Verizon has monitored support newsgroups. There's also some Verizon forums at http://www.dslreports.com/forums/47.
Try running ntptrace to your Verizon-supplied DNS servers and to your gateway. One of them may have decent time.
Another discovery trick is to use traceroute and use ntptrace to inspect your nearby routers. Most big name routers supply ntp if so configured.
Example traceroute redhat.com, or smtp.yourisp.com then I run a quick test of 1,2,3,4
for i in ..... list from traceroute .... do echo ====================== ntptrace $i done
Always ASK your ISP for the service. If they never hear the demand they cannot provide the service.
On Wednesday 22 September 2004 01:34, Kenneth Porter wrote:
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett
gene.heskett@verizon.net wrote:
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
According to http://www.dslreports.com/faq/5825 Verizon has monitored support newsgroups. There's also some Verizon forums at http://www.dslreports.com/forums/47.
Try running ntptrace to your Verizon-supplied DNS servers and to your gateway. One of them may have decent time.
My gateway *is* my router, and ntptrace is silent until it errors out:
[root@coyote root]# ntptrace 199.45.32.43 199.45.32.43: timed out, nothing received ***Request timed out
I can ping it is all.
On Wednesday 22 September 2004 19:21, Nifty Hat Mitch wrote:
On Tue, Sep 21, 2004 at 10:34:23PM -0700, Kenneth Porter wrote:
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
According to http://www.dslreports.com/faq/5825 Verizon has monitored support newsgroups. There's also some Verizon forums at http://www.dslreports.com/forums/47.
Try running ntptrace to your Verizon-supplied DNS servers and to your gateway. One of them may have decent time.
Another discovery trick is to use traceroute and use ntptrace to inspect your nearby routers. Most big name routers supply ntp if so configured.
Example traceroute redhat.com, or smtp.yourisp.com then I run a quick test of 1,2,3,4
for i in ..... list from traceroute .... do echo ====================== ntptrace $i doneAlways ASK your ISP for the service. If they never hear the demand they cannot provide the service.
There was no response from any machine all the way to the secondary dns. Starting locally on the primary traceroute list, I finally hit one on the 17th hop but its a: stratum 16, offset 0.062642, root distance 0.006480
Which brings up 2 questions Tom,
1. WTF is it 18 hops to my primary dns? 2. One would think that in 17 other machines, there would be a timeserver. Obviously these twerps aren't running a thing we don't scream for.
Actually, there's a 3rd question: WTF if the secondary dns doing when it attempts to contact my firewall box on a high port, 32,711 or such as I posted last night? I sent a nastygram to both postmaster and abuse at the secondary dns's name, specifically requesting a reply, but in 18 hours none has been forthcoming. Should I just keep beating on them till they get tired of me and disconnect me, or what?
OT: I like your sig Tom, weak apologies notwithstanding, Danny boy done stepped in it, and he is going to have a disagreeable odor about him for a long long time. Serves him right IMO, news should be first, truthfull, and second, totally issue neutral. Report the facts if they can be proven to be facts, and leave the friggin editorial views on the other side of the news hour. Unforch, CBS hasn't done that in 25 years. Apparently there is no lifeguard at the gene pool anymore.
--On Wednesday, September 22, 2004 11:04 AM -0600 "Rodolfo J. Paiz" rpaiz@simpaticus.com wrote:
By the way, all my DHCP servers provide a pointer to my NTP servers. How do I get clients (Fedora Linux and Windows) to use this pointer? Anyone have any idea? Can't find docs to tell me.
I don't think Windows will use it. What we need is a Win32 client that will issue DHCPINFORM to get the setting and invoke "net time /setsntp" to stash it away, as well as starting the Windows Time service to use it.
For Linux, look at the ISC DHCP client. It has a script that gets all options and rewrites various config files. I believe the RH-provided one clobbers your ntp.conf if that setting is provided and an interface-specific setting doesn't disable the overwrite. Just checked... the package is dhclient (a subpackage of the ISC dhcp SRPM) and the script is /bin/dhclient-script. Browse that to see how it works.
--On Wednesday, September 22, 2004 8:31 PM -0400 Gene Heskett gene.heskett@verizon.net wrote:
Actually, there's a 3rd question: WTF if the secondary dns doing when it attempts to contact my firewall box on a high port, 32,711 or such as I posted last night? I sent a nastygram to both postmaster and abuse at the secondary dns's name, specifically requesting a reply, but in 18 hours none has been forthcoming. Should I just keep beating on them till they get tired of me and disconnect me, or what?
What was the source port? If it's UDP 53, then that's a reply to one of your queries. Sometimes the connection tracking loses the outbound entry so the reply looks like an orphan. Make sure your evidence is very good before accusing someone of shenanigans. Maybe you could post a couple firewall log entries showing what you're seeing? (I haven't seen your other post, maybe you already did that.)
--On Wednesday, September 22, 2004 8:03 PM -0400 Gene Heskett gene.heskett@verizon.net wrote:
Try running ntptrace to your Verizon-supplied DNS servers and to your gateway. One of them may have decent time.
My gateway *is* my router, and ntptrace is silent until it errors out:
[root@coyote root]# ntptrace 199.45.32.43 199.45.32.43: timed out, nothing received ***Request timed out
I can ping it is all.
I meant the router on their end of the wire. But it looks like you don't have any ntp on nearby routers. (I tracerouted to the above address and then ntptraced the last few entries.)
BTW, you might bring this up on the NTP newsgroup. You might find fellow Verizon users there who've been down this path.
On Wed, Sep 22, 2004 at 08:31:12PM -0400, Gene Heskett wrote:
On Wednesday 22 September 2004 19:21, Nifty Hat Mitch wrote:
On Tue, Sep 21, 2004 at 10:34:23PM -0700, Kenneth Porter wrote:
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett
Verizon hasn't volunteered that they have one or more such servers. For me, that would be very nice.
....
Another discovery trick is to use traceroute and use ntptrace to inspect your nearby routers. Most big name routers supply ntp if so configured.
....
There was no response from any machine all the way to the secondary dns.
got to try... now we know.
Starting locally on the primary traceroute list, I finally hit one on the 17th hop but its a: stratum 16, offset 0.062642, root distance 0.006480
Not a problem ... if you traceroute to other 'interesting' places you will get a different list of routers. With a bit of attention you can discover what is close to you.
Which brings up 2 questions Tom,
- WTF is it 18 hops to my primary dns?
The net is getting BIG.
Name servers and smtp boxes are commonly hunkered down in some far off 'safe' location. If you run "dig" on the IP address you posted from I find ;; AUTHORITY SECTION: 88.73.153.141.in-addr.arpa. 52848 IN NS ns1.bellatlantic.net. 88.73.153.141.in-addr.arpa. 52848 IN NS ns2.bellatlantic.net. And then dig on those name servers: ;; AUTHORITY SECTION: bellatlantic.net. 13149 IN NS ns4.verizon.net. bellatlantic.net. 13149 IN NS ns1.bellatlantic.net. bellatlantic.net. 13149 IN NS ns2.verizon.net. bellatlantic.net. 13149 IN NS ns2.bellatlantic.net.
So any three of these (ns[1234]) would be good in your /etc/resolv.conf. Pick ones that have the most 'different' routes for reliability. If you run dig on any of the dhcp assigned host names you are given and look at the NS records you might locate some closer.
- One would think that in 17 other machines, there would be a
timeserver. Obviously these twerps aren't running a thing we don't scream for.
Don't scream just ask.
In the case of NTP most router guys do not look on their boxes as a service resource so they never think to turn ntp on. As long as they route packets the other stuff is extra.
So, In your case use these three ntp hosts. Yes all three. # http://www.pool.ntp.org/ server pool.ntp.org server pool.ntp.org server pool.ntp.org
Actually, there's a 3rd question: WTF if the secondary dns doing when it attempts to contact my firewall box on a high port, 32,711 or such as I posted last night? I sent a nastygram to both postmaster and abuse at the secondary dns's name, specifically requesting a reply, but in 18 hours none has been forthcoming. Should I just keep beating on them till they get tired of me and disconnect me, or what?
Nastygrams only make support folk nasty. In this case the details of their network will be unknown to all but a handful. It does not hurt to ask but it is not worth a nastygram.
As long as the line gets you packets in and out for the right price, not a problem.
A tool like firestarter has knowledge of common port use and translates to human what it can. The rest you need to google. As long as your firewall blocked the connection ... who cares.
Note that traceroute will generate icmp messages back to your box. We can start another thread to research and discuss that topic (routing and icmp) if your Google efforts do not find good answers.
If /etc/services does not help look at header files like these:
/usr/include/netdb.h /usr/include/netinet/in.h ... etc.
Programmers have done some homework on this stuff..
On Thursday 23 September 2004 05:54, Nifty Hat Mitch wrote:
On Wed, Sep 22, 2004 at 08:31:12PM -0400, Gene Heskett wrote:
On Wednesday 22 September 2004 19:21, Nifty Hat Mitch wrote:
On Tue, Sep 21, 2004 at 10:34:23PM -0700, Kenneth Porter wrote:
--On Tuesday, September 21, 2004 11:17 AM -0400 Gene Heskett
[...]
Name servers and smtp boxes are commonly hunkered down in some far off 'safe' location. If you run "dig" on the IP address you posted from I find ;; AUTHORITY SECTION: 88.73.153.141.in-addr.arpa. 52848 IN NS ns1.bellatlantic.net. 88.73.153.141.in-addr.arpa. 52848 IN NS ns2.bellatlantic.net. And then dig on those name servers: ;; AUTHORITY SECTION: bellatlantic.net. 13149 IN NS ns4.verizon.net. bellatlantic.net. 13149 IN NS ns1.bellatlantic.net. bellatlantic.net. 13149 IN NS ns2.verizon.net. bellatlantic.net. 13149 IN NS ns2.bellatlantic.net.
So any three of these (ns[1234]) would be good in your /etc/resolv.conf. Pick ones that have the most 'different' routes for reliability. If you run dig on any of the dhcp assigned host names you are given and look at the NS records you might locate some closer.
- One would think that in 17 other machines, there would be a
timeserver. Obviously these twerps aren't running a thing we don't scream for.
Don't scream just ask.
verizon doesn't seem to hear unless you scream. :)
In the case of NTP most router guys do not look on their boxes as a service resource so they never think to turn ntp on. As long as they route packets the other stuff is extra.
And no doubt someone will come up with a tariff rule that allows them to charge extra for it :(
So, In your case use these three ntp hosts. Yes all three. # http://www.pool.ntp.org/ server pool.ntp.org server pool.ntp.org server pool.ntp.org
Actually, there's a 3rd question: WTF if the secondary dns doing when it attempts to contact my firewall box on a high port, 32,711 or such as I posted last night? I sent a nastygram to both postmaster and abuse at the secondary dns's name, specifically requesting a reply, but in 18 hours none has been forthcoming. Should I just keep beating on them till they get tired of me and disconnect me, or what?
Nastygrams only make support folk nasty. In this case the details of their network will be unknown to all but a handful. It does not hurt to ask but it is not worth a nastygram.
When it costs me a new router for $80+tax, its worth a "nastygram"...
As long as the line gets you packets in and out for the right price, not a problem.
That it does for the most part.
A tool like firestarter has knowledge of common port use and translates to human what it can. The rest you need to google. As long as your firewall blocked the connection ... who cares.
portsentry has blocked many many hack attempts. Back when I was on dialup, I was rarely connected for long enough to get the mail without getting hit. Those who loudly proclaim that an un-protected windows box is owned in 20 seconds aren't being the least bit facetious. But out of many thousands of logged attempts, no one ever got past portsentry (that I know of) yet. And traffic indicated by the modems lights is exclusively generated by my activities
Note that traceroute will generate icmp messages back to your box. We can start another thread to research and discuss that topic (routing and icmp) if your Google efforts do not find good answers.
If /etc/services does not help look at header files like these:
/usr/include/netdb.h /usr/include/netinet/in.h ... etc.
I'll do a read of these, thanks.
Programmers have done some homework on this stuff..
--On Thursday, September 23, 2004 12:04 PM -0400 Gene Heskett gene.heskett@verizon.net wrote:
Nastygrams only make support folk nasty. In this case the details of their network will be unknown to all but a handful. It does not hurt to ask but it is not worth a nastygram.
When it costs me a new router for $80+tax, its worth a "nastygram"...
What about some mystery packets forced you to buy a new router?
Nastygrams are a good way of getting put in the "problem customer" queue, where enough grief will get you dropped. Big companies with little competition have little incentive to spend lots in tech support on any one customer. You have to make friends with the techs to get good results.
On Friday 24 September 2004 01:56, Kenneth Porter wrote:
--On Thursday, September 23, 2004 12:04 PM -0400 Gene Heskett
gene.heskett@verizon.net wrote:
Nastygrams only make support folk nasty. In this case the details of their network will be unknown to all but a handful. It does not hurt to ask but it is not worth a nastygram.
When it costs me a new router for $80+tax, its worth a "nastygram"...
What about some mystery packets forced you to buy a new router?
I have to assume that it was hacked, and the password and ip address was changed. That effectively locked me out from admin'ing it. As I could see traffic on the dsl modems leds when the firewall was shut down, that was grounds enough for me to pull its power plug, pack it back up and hand it back to Circuit City for a refund as it was only 2 weeks old. Who knows what kinds of back doors may have existed in the seimans code... FWIW, I had changed the password from the factory default, for another about 20 chars long.
Nastygrams are a good way of getting put in the "problem customer" queue, where enough grief will get you dropped. Big companies with little competition have little incentive to spend lots in tech support on any one customer. You have to make friends with the techs to get good results.
They also maintain a private newsgroup I log into from time to time. The usual poor service complaints are often ignored, but the really squeeky wheel seems to get a techs attention for a specific local problem.
It took the combined screaming from several hundred of us to finally get corporate to admit they were running an open mail relay, and then another 6 months of screaming because we were all on one or another of the rbl lists before they finally reconfigured them. My impression was that it came very close to the fileing of a class action suit at the time. Unforch, when they are the only non-dialup game in town, you do business with them anyway.
As to whether a request for an ntp server would be given any thought, these guys (and gals) are so well studied on the revelant tariff that it probably won't happen unless the friendly candy company mandates it. Its what happens when you don't have any competition, and no incentive to do better...
On Mon, 20 Sep 2004 15:47:14 +0100, Paul Howarth paul@city-fan.org wrote:
It takes a while to synchronise properly. Give it time.
For the record, it takes 10-15 minutes for ntpd to fully synchronize with its specified servers.
On Tue, Oct 12, 2004 at 05:47:09PM -0700, Kevin Wang wrote:
On Mon, 20 Sep 2004 15:47:14 +0100, Paul Howarth paul@city-fan.org wrote:
It takes a while to synchronise properly. Give it time.
For the record, it takes 10-15 minutes for ntpd to fully synchronize with its specified servers.
It might be quicker than Paul expects. On a test box, I stopped the ntpd service and forced the local time-of-day to be about 10 min ahead of a box with very good time.
Then back on the test box I restarted ntpd
# service ntp start
Watching the time with a loop and ssh.
======================== Tue Oct 12 18:02:32 PDT 2004 local known good Tue Oct 12 18:14:27 PDT 2004 ======================== Tue Oct 12 18:03:02 PDT 2004 local known good Tue Oct 12 18:03:03 PDT 2004 ======================== Tue Oct 12 18:03:33 PDT 2004 local known good Tue Oct 12 18:03:33 PDT 2004
So wall time can be very good inside of a min.
On Tue, 12 Oct 2004 18:10:23 -0700, Nifty Hat Mitch mitch48@sbcglobal.net wrote:
It might be quicker than Paul expects. ...
So wall time can be very good inside of a min.
You sure the machine isn't setup to first ntpdate against the servers? shrug. my experience is from a redhat 7 or 8 derivation from a few years ago. I distinctly remember this because it was a real pain trying to debug ntpd because I had to wait 10 minutes to verify that my changes worked right.
- Kevin
On Tue, Oct 12, 2004 at 06:33:14PM -0700, Kevin Wang wrote:
On Tue, 12 Oct 2004 18:10:23 -0700, Nifty Hat Mitch mitch48@sbcglobal.net wrote:
It might be quicker than Paul expects. ...
So wall time can be very good inside of a min.
You sure the machine isn't setup to first ntpdate against the servers? shrug. my experience is from a redhat 7 or 8 derivation from a few years ago. I distinctly remember this because it was a real pain trying to debug ntpd because I had to wait 10 minutes to verify that my changes worked right.
It is true that "service ntpd start" does a list of things.
One of the things it does do is an ntpdate in advance of ntpd. It also interacts with the firewall which is while
I do use "service ntpd start" for no other reason than it does things I like with ip filters.. I could hack it and see how long it does take to sync ....
-
Brian Fahrlander -
Doncho N. Gunchev -
Gene Heskett -
jdow -
John DeDourek -
Kenneth Porter -
Kevin Wang -
Michael -
Mike McMullen -
Paul Howarth -
Rodolfo J. Paiz -
Thomas Zehetbauer -
Tom Mitchell