local NTP server not used by clients. Setup issue
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I have a local net with no internet and want to keep all computers in there time synced. I do not care about the absolute time, it should just be the same for all.
I found several posts about this. The most useful ones were:
- How do I setup a local NTP server?
- Setting up a standalone NTP server on Ubuntu
server
I did setup the server with the IP 192.168.1.123 and it seems to be working ok: The deamon "ntpd" is running and I had been adding in etc/ntp.conf the lines
# this sets the source to local time
server 127.127.1.0
fudge 127.127.1.0 stratum 8
# this makes the ntpd deamon to send out its time on the local net.
broadcast 192.168.255.255
I verified it with the ntpq command:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.255.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
"BCST" says its in broadcast more and the IP shows its broadcasting to all computers on the local net (a B class network, thus 2x 255).
client
On client side I also installed ntp, and used the default /etc/ntp.conf and added the lines
server 192.168.1.123 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 8
where 192.168.1.123 is the local IP of the server broadcasting and the other line should tell the client (a laptop) to use its own clock when the network connection is off. I restarted the service on the client and ran ntpq to check the connection
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Repeating this command I can see the "when" column counting up both and starting with 0 again when reaching 64sec. I did expect after the 64 sec this would change to this:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Note the "*" before the server IP. But it did not. What I got after about 1hr was
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
*LOCAL(0) .LOCL. 8 l 63 64 377 0.000 0.000 0.000
I think this tells me, there are 2 sources for NTP configured, but as the remote source is not working/not available/whatever it is not used and the fallback case local clock is used, but I am not sure if that interpretation is correct.
what I tried
I waited more than 1hr, I restarted the ntpd
serveral times with sudo /etc/init.d/ntp restart
and I also rebooted. Further I commented out the local section clock so that the only server was server 192.168.1.123
. I could not get that "*" to appear. Also I saw a section in the ntp.conf that said
#if you want to listen to time broadcasts on you local subnet,
#de-comment the next lines. Please do this only if you trust
#everybody on the network!
#disable auth
#broadcastclient
I tried un-commenting and restarting the service but still that star did not appear. I am wondering about the last section, though, because this section did turn up in any other post or internet result that I saw on the ntp configuration. There are several ones on local setups and most seem to be find with the server address alone. Ping from client to server is fine. There is not firewall etc.
question
I am out of ideas. I think I have a server with fully working ntp server which is sending out the time. But I do have a client which is failing to receive the time information from the server.
What can I do to get the client running?
networking server configuration ntp
add a comment |
I have a local net with no internet and want to keep all computers in there time synced. I do not care about the absolute time, it should just be the same for all.
I found several posts about this. The most useful ones were:
- How do I setup a local NTP server?
- Setting up a standalone NTP server on Ubuntu
server
I did setup the server with the IP 192.168.1.123 and it seems to be working ok: The deamon "ntpd" is running and I had been adding in etc/ntp.conf the lines
# this sets the source to local time
server 127.127.1.0
fudge 127.127.1.0 stratum 8
# this makes the ntpd deamon to send out its time on the local net.
broadcast 192.168.255.255
I verified it with the ntpq command:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.255.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
"BCST" says its in broadcast more and the IP shows its broadcasting to all computers on the local net (a B class network, thus 2x 255).
client
On client side I also installed ntp, and used the default /etc/ntp.conf and added the lines
server 192.168.1.123 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 8
where 192.168.1.123 is the local IP of the server broadcasting and the other line should tell the client (a laptop) to use its own clock when the network connection is off. I restarted the service on the client and ran ntpq to check the connection
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Repeating this command I can see the "when" column counting up both and starting with 0 again when reaching 64sec. I did expect after the 64 sec this would change to this:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Note the "*" before the server IP. But it did not. What I got after about 1hr was
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
*LOCAL(0) .LOCL. 8 l 63 64 377 0.000 0.000 0.000
I think this tells me, there are 2 sources for NTP configured, but as the remote source is not working/not available/whatever it is not used and the fallback case local clock is used, but I am not sure if that interpretation is correct.
what I tried
I waited more than 1hr, I restarted the ntpd
serveral times with sudo /etc/init.d/ntp restart
and I also rebooted. Further I commented out the local section clock so that the only server was server 192.168.1.123
. I could not get that "*" to appear. Also I saw a section in the ntp.conf that said
#if you want to listen to time broadcasts on you local subnet,
#de-comment the next lines. Please do this only if you trust
#everybody on the network!
#disable auth
#broadcastclient
I tried un-commenting and restarting the service but still that star did not appear. I am wondering about the last section, though, because this section did turn up in any other post or internet result that I saw on the ntp configuration. There are several ones on local setups and most seem to be find with the server address alone. Ping from client to server is fine. There is not firewall etc.
question
I am out of ideas. I think I have a server with fully working ntp server which is sending out the time. But I do have a client which is failing to receive the time information from the server.
What can I do to get the client running?
networking server configuration ntp
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with aserver a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.
– CatMan
Feb 20 '17 at 20:02
add a comment |
I have a local net with no internet and want to keep all computers in there time synced. I do not care about the absolute time, it should just be the same for all.
I found several posts about this. The most useful ones were:
- How do I setup a local NTP server?
- Setting up a standalone NTP server on Ubuntu
server
I did setup the server with the IP 192.168.1.123 and it seems to be working ok: The deamon "ntpd" is running and I had been adding in etc/ntp.conf the lines
# this sets the source to local time
server 127.127.1.0
fudge 127.127.1.0 stratum 8
# this makes the ntpd deamon to send out its time on the local net.
broadcast 192.168.255.255
I verified it with the ntpq command:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.255.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
"BCST" says its in broadcast more and the IP shows its broadcasting to all computers on the local net (a B class network, thus 2x 255).
client
On client side I also installed ntp, and used the default /etc/ntp.conf and added the lines
server 192.168.1.123 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 8
where 192.168.1.123 is the local IP of the server broadcasting and the other line should tell the client (a laptop) to use its own clock when the network connection is off. I restarted the service on the client and ran ntpq to check the connection
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Repeating this command I can see the "when" column counting up both and starting with 0 again when reaching 64sec. I did expect after the 64 sec this would change to this:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Note the "*" before the server IP. But it did not. What I got after about 1hr was
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
*LOCAL(0) .LOCL. 8 l 63 64 377 0.000 0.000 0.000
I think this tells me, there are 2 sources for NTP configured, but as the remote source is not working/not available/whatever it is not used and the fallback case local clock is used, but I am not sure if that interpretation is correct.
what I tried
I waited more than 1hr, I restarted the ntpd
serveral times with sudo /etc/init.d/ntp restart
and I also rebooted. Further I commented out the local section clock so that the only server was server 192.168.1.123
. I could not get that "*" to appear. Also I saw a section in the ntp.conf that said
#if you want to listen to time broadcasts on you local subnet,
#de-comment the next lines. Please do this only if you trust
#everybody on the network!
#disable auth
#broadcastclient
I tried un-commenting and restarting the service but still that star did not appear. I am wondering about the last section, though, because this section did turn up in any other post or internet result that I saw on the ntp configuration. There are several ones on local setups and most seem to be find with the server address alone. Ping from client to server is fine. There is not firewall etc.
question
I am out of ideas. I think I have a server with fully working ntp server which is sending out the time. But I do have a client which is failing to receive the time information from the server.
What can I do to get the client running?
networking server configuration ntp
I have a local net with no internet and want to keep all computers in there time synced. I do not care about the absolute time, it should just be the same for all.
I found several posts about this. The most useful ones were:
- How do I setup a local NTP server?
- Setting up a standalone NTP server on Ubuntu
server
I did setup the server with the IP 192.168.1.123 and it seems to be working ok: The deamon "ntpd" is running and I had been adding in etc/ntp.conf the lines
# this sets the source to local time
server 127.127.1.0
fudge 127.127.1.0 stratum 8
# this makes the ntpd deamon to send out its time on the local net.
broadcast 192.168.255.255
I verified it with the ntpq command:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.255.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
"BCST" says its in broadcast more and the IP shows its broadcasting to all computers on the local net (a B class network, thus 2x 255).
client
On client side I also installed ntp, and used the default /etc/ntp.conf and added the lines
server 192.168.1.123 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 8
where 192.168.1.123 is the local IP of the server broadcasting and the other line should tell the client (a laptop) to use its own clock when the network connection is off. I restarted the service on the client and ran ntpq to check the connection
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Repeating this command I can see the "when" column counting up both and starting with 0 again when reaching 64sec. I did expect after the 64 sec this would change to this:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Note the "*" before the server IP. But it did not. What I got after about 1hr was
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
*LOCAL(0) .LOCL. 8 l 63 64 377 0.000 0.000 0.000
I think this tells me, there are 2 sources for NTP configured, but as the remote source is not working/not available/whatever it is not used and the fallback case local clock is used, but I am not sure if that interpretation is correct.
what I tried
I waited more than 1hr, I restarted the ntpd
serveral times with sudo /etc/init.d/ntp restart
and I also rebooted. Further I commented out the local section clock so that the only server was server 192.168.1.123
. I could not get that "*" to appear. Also I saw a section in the ntp.conf that said
#if you want to listen to time broadcasts on you local subnet,
#de-comment the next lines. Please do this only if you trust
#everybody on the network!
#disable auth
#broadcastclient
I tried un-commenting and restarting the service but still that star did not appear. I am wondering about the last section, though, because this section did turn up in any other post or internet result that I saw on the ntp configuration. There are several ones on local setups and most seem to be find with the server address alone. Ping from client to server is fine. There is not firewall etc.
question
I am out of ideas. I think I have a server with fully working ntp server which is sending out the time. But I do have a client which is failing to receive the time information from the server.
What can I do to get the client running?
networking server configuration ntp
networking server configuration ntp
edited Apr 13 '17 at 12:23
Community♦
1
1
asked Feb 20 '17 at 13:16
CatManCatMan
562622
562622
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with aserver a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.
– CatMan
Feb 20 '17 at 20:02
add a comment |
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with aserver a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.
– CatMan
Feb 20 '17 at 20:02
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with a
server a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.– CatMan
Feb 20 '17 at 20:02
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with a
server a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.– CatMan
Feb 20 '17 at 20:02
add a comment |
1 Answer
1
active
oldest
votes
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd
instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd
or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd
to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf
file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a *
before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT.
it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *
):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntp
should 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f885345%2flocal-ntp-server-not-used-by-clients-setup-issue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd
instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd
or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd
to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf
file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a *
before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT.
it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *
):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntp
should 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
add a comment |
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd
instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd
or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd
to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf
file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a *
before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT.
it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *
):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntp
should 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
add a comment |
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd
instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd
or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd
to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf
file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a *
before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT.
it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *
):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntp
should 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd
instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd
or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd
to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf
file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a *
before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT.
it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *
):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntp
should 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
edited 34 mins ago
Can
32
32
answered Feb 20 '17 at 21:52
CatManCatMan
562622
562622
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f885345%2flocal-ntp-server-not-used-by-clients-setup-issue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
When you are sending the time on the broadcast address, should the clients not be listening on that address, instead of the servers address, that do not send any time-sync?
– Ken Mollerup
Feb 20 '17 at 16:45
@kenMollerup please correct me if I am wrong, but there would be little point in a broadcast address when the receivers need to be listing to that broadcast address specifically in order to get a message. I would expect all clients listening on port 123 will get a message. The message appears to them to be sent to <OwnclientIP>:123, right? However, what you say could explain the config file sections send broadcast and listen to broadcasts. I tried with that listening section enabled but no success. Do you know any other way (beside the broadcast) to make the server sent out its time?
– CatMan
Feb 20 '17 at 17:39
No, but what use are the servers address when the info is on the broadcast address ?
– Ken Mollerup
Feb 20 '17 at 17:48
@KenMollenrup While thinking about your question I think I resolved the confusion I had. ntpd can be server and client at the same time. It works by polling. In a stand alone network a NTP server does nothing but reading its local clock and wait for clients to send requests. Broadcasting is an atypical mode. A client is anyone with a
server a.b.c.d
statement. That makes it polling those servers. From a setup point of view there is no server setup at all. Unless explicitly forbidden, any ntpd instance answer requests (=is a server). However, I still wonder why my initial setup failes.– CatMan
Feb 20 '17 at 20:02