Re: [Dorset] Setting up an NTP Server in a Closed Network
On Thursday, 24 August 2017 13:48:59 BST Terry Coles wrote: > On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote: > > ntp-wait(1) might be of interest: "This can be useful at boot time, to > > delay the boot sequence until after ntpd -g has set the time". > > That is definitely of interest. If all else fails, then this could ensure > that the clocks are synced before we try to run our software. > > However, the man page isn't very helpful with respect to when to launch it > and where from. Since there isn't much point in delaying the start of the > system until NTP itself has started, then I'm assuming that I could put it > into rc.local, except that this file has the following comment in it: > > # This script is executed at the end of each multiuser runlevel. > > If it waits until the end of the runlevel, is that too late? Presumably, as > long as further processing is delayed before we launch our software from > .bashrc, we should be OK. Ralph, Well I tried it in rc.local and it works. It is an interesting experience, because although it does hold up further booting until sync occurs, messages continue to arrive from the boot process for a short time. I assume that this is upstart in action, eg the residual messages come from boot activities triggered by upstart before the command is executed, but which hadn't finished. Anyway, the system then sits there doing next to nothing until the clock syncs (you get a rather abrupt OK) and then our software starts immediately after. I'd still like to know if there is a solution to the 10 minutes of KoDs, but this will work and it isn't as if we are trying to control something that needs microsecond response times. Thanks for your help. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote: > Where was this script? I forgotten upstart, but it probably still copes > with scripts in /etc/init.d. If it's one of those, see update-rc.d(8). > https://debian-handbook.info/browse/stable/unix-services.html#sect.system-bo > ot The script that I modified was the standard one to start ntpd. It is installed in /etc/init.d. Anyway, I've moved on a bit since then (see below). > I notice date(1) says UTC on one machine, and GMT on the other. The I hadn't spotted that. I'll make them the same. > `-q' could do with a `-g' if you expect the discrepancy to be large. > The `KoD... inconsistent xmt/org/rec timestamps. Ignoring.' that last > some minutes are because the incoming packets from the server don't have > those three timestamps set to the xmt one that was sent out. I don't > know why that would be. Yes. I kind of worked out what the error was, but not necessarily the cause. > > As you can see, the sync is quicker, but it still took nearly 5 > > minutes. I'm not sure why the daemon takes that long, but it may be > > as good as it gets. Does anyone know? > > Not getting those `ignoring' messages will probably shorten that. Wouldn't that be nice :-) > > Final question; I can only start ntpd as root, so I intend to put the > > startup line in the /etc/ rc.local. > > If it's installed as a package then it will have a start-up script to > enable, as pointed to above. Look at the contents of the package with > `dpkg -l $packagename'. I think that your ntp-wait (see below) is a better approach anyway. > > I now understand a little more about the Kiss of Death packet that is > > being sent by the server. I have discovered that the server is > > comparing timestamps from the RTC and the system files and suppressing > > the transmission of a valid signal until they are consistent, but why > > they shouldn't be I'm not sure. > > Was https://afterthoughtsoftware.com/products/rasclock closely followed > on installation? Look at dmesg(1) output after booting and see if it > mentions clocks or time sources. Could the `fake-hwclock' they ship in > Raspbian be interfering? I revisited the config instructions at that link and discovered that I'd missed out a step ;-( That's the penalty of having the instructions on one screen and the file being edited on another in a room at other end of the house! I've fixed that now, but I need to leave time for the RTC to get it wrong again, in case there is still some error somewhere. > > Bad news this morning I'm afraid. I turned on the system to confirm > > yesterday's results and ran 'sudo ntpd -q' immediately after buttspi > > had booted, exactly as I did yesterday. The daemon reported its > > progress, exactly as before, but it exited without syncing. I tried a > > few more times with the same results. > > That could be the lack of -g mentioned above. I tried this several more times and then went back to the default method of launching ntpd. After approx 10 minutes the clocks synced. I'll investigate the discrepancy between the timezones on the two devices and see if that helps. > ntp-wait(1) might be of interest: "This can be useful at boot time, to > delay the boot sequence until after ntpd -g has set the time". That is definitely of interest. If all else fails, then this could ensure that the clocks are synced before we try to run our software. However, the man page isn't very helpful with respect to when to launch it and where from. Since there isn't much point in delaying the start of the system until NTP itself has started, then I'm assuming that I could put it into rc.local, except that this file has the following comment in it: # This script is executed at the end of each multiuser runlevel. If it waits until the end of the runlevel, is that too late? Presumably, as long as further processing is delayed before we launch our software from .bashrc, we should be OK. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
Hi Terry, > I then did as Ralph originally suggested and stopped the NTP service > from running. (I wasn't sure how to do this, so I added and exit 0 to > the beginning of the script, which seemed to work OK. If there's a > better way, I'd be interested to hear it.) Where was this script? I forgotten upstart, but it probably still copes with scripts in /etc/init.d. If it's one of those, see update-rc.d(8). https://debian-handbook.info/browse/stable/unix-services.html#sect.system-boot > I then executed 'sudo ntpd -q' after logging into [buttspi]. I've put > the screenshot of the results at: > > http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png I notice date(1) says UTC on one machine, and GMT on the other. The `-q' could do with a `-g' if you expect the discrepancy to be large. The `KoD... inconsistent xmt/org/rec timestamps. Ignoring.' that last some minutes are because the incoming packets from the server don't have those three timestamps set to the xmt one that was sent out. I don't know why that would be. > As you can see, the sync is quicker, but it still took nearly 5 > minutes. I'm not sure why the daemon takes that long, but it may be > as good as it gets. Does anyone know? Not getting those `ignoring' messages will probably shorten that. > Final question; I can only start ntpd as root, so I intend to put the > startup line in the /etc/ rc.local. If it's installed as a package then it will have a start-up script to enable, as pointed to above. Look at the contents of the package with `dpkg -l $packagename'. > I now understand a little more about the Kiss of Death packet that is > being sent by the server. I have discovered that the server is > comparing timestamps from the RTC and the system files and suppressing > the transmission of a valid signal until they are consistent, but why > they shouldn't be I'm not sure. Was https://afterthoughtsoftware.com/products/rasclock closely followed on installation? Look at dmesg(1) output after booting and see if it mentions clocks or time sources. Could the `fake-hwclock' they ship in Raspbian be interfering? > Bad news this morning I'm afraid. I turned on the system to confirm > yesterday's results and ran 'sudo ntpd -q' immediately after buttspi > had booted, exactly as I did yesterday. The daemon reported its > progress, exactly as before, but it exited without syncing. I tried a > few more times with the same results. That could be the lack of -g mentioned above. > I then checked the time on sumppi and the RTC had lost nearly an hour > overnight. I can't understand this; the battery seems fine, it kept > good time on Tuesday night, although it kept bad time last night and > on Monday night. > > I'm going to put the RTC onto one of my Pis this afternoon and see if > it keeps good time on that. With the SD card so its the same hardware and software? I suspect the OS and distribution are fighting over the source of time at start up. ntp-wait(1) might be of interest: "This can be useful at boot time, to delay the boot sequence until after ntpd -g has set the time". Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 19:42:02 BST Terry Coles wrote: > On Wednesday, 23 August 2017 18:10:45 BST Terry Coles wrote: > > I then executed 'sudo ntpd -q' after logging into buttspi. I've put the > > screenshot of the results at: > > > > http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png > > > > As you can see, the sync is quicker, but it still took nearly 5 minutes. > > I'm not sure why the daemon takes that long, but it may be as good as it > > gets. Does anyone know? Is it because it takes that long for the RTC and > > the System Clock on the server to home in on each other? Bad news this morning I'm afraid. I turned on the system to confirm yesterday's results and ran 'sudo ntpd -q' immediately after buttspi had booted, exactly as I did yesterday. The daemon reported its progress, exactly as before, but it exited without syncing. I tried a few more times with the same results. I then checked the time on sumppi and the RTC had lost nearly an hour overnight. I can't understand this; the battery seems fine, it kept good time on Tuesday night, although it kept bad time last night and on Monday night. I'm going to put the RTC onto one of my Pis this afternoon and see if it keeps good time on that. Does anyone have any ideas why the RTC should be so erratic? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 18:10:45 BST Terry Coles wrote: > I then executed 'sudo ntpd -q' after logging into buttspi. I've put the > screenshot of the results at: > > http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png > > As you can see, the sync is quicker, but it still took nearly 5 minutes. > I'm not sure why the daemon takes that long, but it may be as good as it > gets. Does anyone know? Is it because it takes that long for the RTC and > the System Clock on the server to home in on each other? I now understand a little more about the Kiss of Death packet that is being sent by the server. I have discovered that the server is comparing timestamps from the RTC and the system files and suppressing the transmission of a valid signal until they are consistent, but why they shouldn't be I'm not sure. It may be that is as good as it gets when the server has only just started. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 18:10:45 BST Terry Coles wrote: > I then executed 'sudo ntpd -q' after logging into sumppi. I've put the ^^ buttspi -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 15:44:18 BST Terry Coles wrote: > I've done a bit more research and discovered that it's not systemd that > allows services to start in parallel, but upstart. Raspbian Stretch does > use upstart, so I'm thinking that putting a delay in the ntp startup script > shouldn't have a major effect on the system running. Answering myself again. I tried putting a delay into the ntp service startup script, but it still took approximately 10 minutes to sync, so it's not worth doing it that way. I then did as Ralph originally suggested and stopped the NTP service from running. (I wasn't sure how to do this, so I added and exit 0 to the beginning of the script, which seemed to work OK. If there's a better way, I'd be interested to hear it.) I then executed 'sudo ntpd -q' after logging into sumppi. I've put the screenshot of the results at: http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png As you can see, the sync is quicker, but it still took nearly 5 minutes. I'm not sure why the daemon takes that long, but it may be as good as it gets. Does anyone know? Is it because it takes that long for the RTC and the System Clock on the server to home in on each other? Final question; I can only start ntpd as root, so I intend to put the startup line in the /etc/ rc.local . However, I still need to delay it's execution long enough to allow sumppi and the switch to get going. Is there a better way? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 14:30:12 BST Terry Coles wrote: > Raspberry Pi Stretch is running systemd but the ntpd service file is > installed in /etc/init.d. From this, I'm assuming that if I made a copy of > the ntp.service file and put a delay into it, that would work, but will > this delay the whole boot cycle? I'm vaguely aware that the latest linux > boot techniques allow services to start in parallel, but I'm not sure if > this applies to services that would have been started by init in days of > yore. I've done a bit more research and discovered that it's not systemd that allows services to start in parallel, but upstart. Raspbian Stretch does use upstart, so I'm thinking that putting a delay in the ntp startup script shouldn't have a major effect on the system running. Anyone have any thoughts on this? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 10:35:16 BST Ralph Corderoy wrote: > > If that proves to be the case, we'll have to delay for a while before > > we do anything or put an RTC on the client Pi and only use NTP to sync > > the two clocks. > > One used to use ntpdate(1) for a one-shot, set this machine's clock from > an NTP source now, command. Its man page suggests `ntpd -q' it the > modern method, having ntpd quit once its work is done. You might want > to have the client do that soon after boot. Ralph, OK. I've established that my RTC is working and keeping good time and I now am certain that the NTP client is syncing to the server after around 10 minutes or so. I think our problem is almost certainly because all the hardware in the system is starting at the same time; that is the Network Switch, the Sump Pi and the Butts Pi all get their power together. We've already delayed the taking of measurements to give the network a chance to get up and running, but I suspect that delaying the start of the NTP Daemon on the sumppi for a minute or so might well improve the sync time. So my last question is, what is the best way to do this? Raspberry Pi Stretch is running systemd but the ntpd service file is installed in /etc/init.d. From this, I'm assuming that if I made a copy of the ntp.service file and put a delay into it, that would work, but will this delay the whole boot cycle? I'm vaguely aware that the latest linux boot techniques allow services to start in parallel, but I'm not sure if this applies to services that would have been started by init in days of yore. What do you think? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
Hi Terry, > > https://www.eecis.udel.edu/~mills/ntp/html/debug.html has some other > > things to try. > > That last link has a lot of useful information (and even more in the > links within that page). It's probably just an online copy of the contents of the ntp-doc package, and getting that will mean you'll have documentation that matches your version. https://packages.debian.org/wheezy/all/ntp-doc/filelist Another way to debug is to catch network packets on either or both machines with something like sudo tcpdump -w sump.pck port ntp and then analyse them in Wireshark later. > If that proves to be the case, we'll have to delay for a while before > we do anything or put an RTC on the client Pi and only use NTP to sync > the two clocks. One used to use ntpdate(1) for a one-shot, set this machine's clock from an NTP source now, command. Its man page suggests `ntpd -q' it the modern method, having ntpd quit once its work is done. You might want to have the client do that soon after boot. > That's pretty much what we've been doing. You may be interested to know about screen(1)'s `hardcopy' and `log' commands. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Tuesday, 22 August 2017 17:36:34 BST Ralph Corderoy wrote: > > http://hadrian-way.co.uk/Misc/Pi_NTP_Screenshot.png > > Were there any status characters in front of the `remote' IP address in > the top left, do you recall? I don't think so, but I've seen an asterisk in front of 127.127.1.0 (I think) since I added it to the servers list. Apart from this problem, I currently also have a Real Time Clock issue (It seems to drift), so I've done some work on that and shut it down for the night to see what happens to the time after a decent delay. > Can anyone else think what i may be doing wrong? One thing I've noticed > in the output of ntpq -pn is that the 'refid' column contains terms such > as '.XFAC', '.LOC' or '.INIT' > > `refid', if not an IP address, is a KISS code. Not Simple, Stupid, but > Kiss-o'-Death. > https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-par Thanks for that, although I don't see either XFAC or LOC in that list. > ameters-2 Your XFAC may be because an interface has changed address > http://lists.ntp.org/pipermail/questions/2010-May/026725.html Thanks for that link.. > I'd stop the NTP stuff running at boot. Boot both Pis. Ensure their > wired interfaces are up with the expected addresses, and work, e.g. you > can ssh from sump to butts, and then back to sump. Then start the ntpd > on sump without having it go into the background. Its status messages > will then appear as you watch. Once it seems happy, then get to butts > and start that side. > https://www.eecis.udel.edu/~mills/ntp/html/debug.html has some other > things to try. That last link has a lot of useful information (and even more in the links within that page). Studying that will give me something to do while I wait for the RTC to reveal its accuracy. I noticed an interesting statement on that page: 'Unless using the iburst option, the client normally takes a few minutes to synchronize to a server. ' Just before I shut down the system for the final time today, I ran date on the client and the time appeared to be correct. Maybe that's all the problem has been; we have to wait for the client to sync. I had been running hwclock -c on sumppi for around 20 minutes at the time. We've generally been booting the two Pi's together (they are both powered from a 19 V PSU connected directly to a DC-DC converter on sumppi and via PoE to another DC- DC converter on buttspi). We then ran date on both machines pretty much straight away, so we maybe never waited long enough. If that proves to be the case, we'll have to delay for a while before we do anything or put an RTC on the client Pi and only use NTP to sync the two clocks. > If you've only a keyboard and monitor on sump to a single TTY, no X, > then screen(1) can be useful to kick off other pseudo TTYs so you can > run the NTP server on one, ssh to butts on another, ... That's pretty much what we've been doing. Thanks for your help. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
Hi Terry, > I've examined the output of ntpq -pn, but it doesn't reveal anything > to me that seems untoward, except that the both the Master and Remote > Pis list 192.168.0.2 as the remote. See: > > http://hadrian-way.co.uk/Misc/Pi_NTP_Screenshot.png Were there any status characters in front of the `remote' IP address in the top left, do you recall? Can anyone else think what i may be doing wrong? One thing I've noticed in the output of ntpq -pn is that the 'refid' column contains terms such as '.XFAC', '.LOC' or '.INIT' `refid', if not an IP address, is a KISS code. Not Simple, Stupid, but Kiss-o'-Death. https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-2 Your XFAC may be because an interface has changed address. http://lists.ntp.org/pipermail/questions/2010-May/026725.html I'd stop the NTP stuff running at boot. Boot both Pis. Ensure their wired interfaces are up with the expected addresses, and work, e.g. you can ssh from sump to butts, and then back to sump. Then start the ntpd on sump without having it go into the background. Its status messages will then appear as you watch. Once it seems happy, then get to butts and start that side. https://www.eecis.udel.edu/~mills/ntp/html/debug.html has some other things to try. If you've only a keyboard and monitor on sump to a single TTY, no X, then screen(1) can be useful to kick off other pseudo TTYs so you can run the NTP server on one, ssh to butts on another, ... Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Monday, 21 August 2017 16:32:12 BST Terry Coles wrote: > For the Client we've added: > > server 192.168.0.2 > > to the server pool. > > For the Server we've added: > > restrict 192.168.0.0 mask 255.255.255.0 > > and: > >broadcast 192.168.0.255 > > However, it doesn't work. > I've examined the output of ntpq -pn, but it doesn't reveal anything to me > that seems untoward, except that the both the Master and Remote Pis list > 192.168.0.2 as the remote. See: > > http://hadrian-way.co.uk/Misc/Pi_NTP_Screenshot.png It still doesn't work. I've trawled the net for ideas and tried quite a few, but nothing seems to make any difference. Can anyone else think what i may be doing wrong? One thing I've noticed in the output of ntpq -pn is that the 'refid' column contains terms such as '.XFAC', '.LOC' or '.INIT', depending on which of the different fixes I've tried, whereas all the examples that I've found on the net seem to refer to another IP Address. I'm assuming that these examples show the results when a device is fully connected to an NTP server on the web, whereas, I'm trying to make my Pi an NTP server, so there's nothing else to refer to. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Monday, 21 August 2017 17:30:18 BST Terry Coles wrote: > > Add the following two lines to your servers config. > > > > server 127.127.1.0 > > fudge 127.127.1.0 stratum 12 > > Hmmm. I tried that and still nogo. Should that have been 127.0.0.1? (I > tried that and it still didn't work.) Just discovered that 127.127.1.0 is correct. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Monday, 21 August 2017 16:56:50 BST Bob Dunlop wrote: > Everything is sitting at stratum 16 "no trusted clocks", the server won't > offer a syncronisation service at this level. > > The server needs a clock it trusts before it will serve the time. > > Add the following two lines to your servers config. > > server 127.127.1.0 > fudge 127.127.1.0 stratum 12 Hmmm. I tried that and still nogo. Should that have been 127.0.0.1? (I tried that and it still didn't work.) Should those entries be on the Server or the Client (I tried both but) > This tells the server to use the system clock as a reference at stratum > 12. System clock on a Pi is a poor choice since the Pi doesn't have an > RTC so will get clobbered on every power cycle but it should get you > going. I forgot to mention; I have included a RASClock RTC on the Master Pi. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
Hi, On Mon, Aug 21 at 04:32, Terry Coles wrote: ... > However, it doesn't work. Everything is sitting at stratum 16 "no trusted clocks", the server won't offer a syncronisation service at this level. The server needs a clock it trusts before it will serve the time. Add the following two lines to your servers config. server 127.127.1.0 fudge 127.127.1.0 stratum 12 This tells the server to use the system clock as a reference at stratum 12. System clock on a Pi is a poor choice since the Pi doesn't have an RTC so will get clobbered on every power cycle but it should get you going. -- Bob Dunlop -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
[Dorset] Setting up an NTP Server in a Closed Network
Hi, We've been trying to set up a local NTP Server on our WMT network which consists of a Wireless AP (we're not connecting to the Internet), the 'Master' Pi and a 'Remote' Pi. The Wireless AP is only there for debugging and to act as a Switch and the Pi's are interconnected with Cat 5 cable. Here is what we have done: 1. Allocated static IP addresses to both Pis and restricted the DHCP range on the Wireless AP to avoid conflicts. The Master Pi is 192.168.0.2 and the Remote Pi is 192.168.0.3. 2. Followed the instructions at http://raspberrypi.tomasgreno.cz/ntp-client-and-server.html setting the Remote Pi as the Client and the Master Pi as the Server. For the Client we've added: server 192.168.0.2 to the server pool. For the Server we've added: restrict 192.168.0.0 mask 255.255.255.0 and: broadcast 192.168.0.255 However, it doesn't work. I've examined the output of ntpq -pn, but it doesn't reveal anything to me that seems untoward, except that the both the Master and Remote Pis list 192.168.0.2 as the remote. See: http://hadrian-way.co.uk/Misc/Pi_NTP_Screenshot.png Any ideas? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
