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;
}







3















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?










share|improve this question

























  • 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


















3















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?










share|improve this question

























  • 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














3












3








3








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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



















  • 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

















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










1 Answer
1






active

oldest

votes


















0














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 ntpshould 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.






share|improve this answer


























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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 ntpshould 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.






    share|improve this answer






























      0














      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 ntpshould 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.






      share|improve this answer




























        0












        0








        0







        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 ntpshould 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.






        share|improve this answer















        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 ntpshould 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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 34 mins ago









        Can

        32




        32










        answered Feb 20 '17 at 21:52









        CatManCatMan

        562622




        562622






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            GameSpot

            日野市

            Tu-95轟炸機