Even though the AREDN mesh doesn't really use time for much ("NTP is only for display purposes"), it seems only right to have it correctly set. And, if you're truly getting ready for a general failure of public services, having the correct time to distribute on your mesh might be quite valuable.
Here's one relatively easy way to do it - I did it, it can't be that hard!
1 - get a Raspberry Pi (we use a Pi3, also makes nice webserver);
2 - pick a node where you can set "Disable Default Route" and do so (Setup);
3 - setup the NTP service on the PI itself (and lots of other stuff?) - you can either use a second network adapter for an internet connection for NTP coordination (*see below) -or- get a little GPS dongle and extract the time from it (also, you could manually control the time if you need thru the PI);
4 - attach your little PI to your node (give it nice clean 5V/2.5A power) as a LAN device, maybe thru a switch, and give it a name like "OurMeshServer" using a dedicated/fixed DHCP address for it (get the name spelling right the first time - the mesh can be problematic on later name changes etc);
5 - this entry really does NOT need a "link" nor an advertised "service" to allow NTP access by others on the mesh, just the DNS name;
6 - this will get you a routable DNS entry for "OurMeshServer.local.mesh" as your NTP server and it will show on all Mesh Status Screens as a non-clickable entry under your node;
7 - count your fingers and toes, and then reboot the "server" node;
8- update whatever mesh nodes you wish to have the correct time by setting the timezone and entering OurMeshServer.local.mesh as your NTP server (Basic Setup/Optional Services);
9 - reboot the client node - the updated node will refresh its time a few minutes after POST and DNS sync (have a cold beer and wait patiently).
For more background on this, see the prior post thread at https://www.arednmesh.org/content/use-raspberry-pi3-meshwebserver
My very sincere thanks to KG6JEI for the help and direction given in that thread.
*NB: In our mesh we do NOT use "gateways" or "tunnels" to other networks, our mesh is self-contained. So, if you check the box labeled "Disable Default Route" then all devices attached to that node will only attempt to route traffic thru there that is specifically for the 10.x.x.x/local.mesh space - otherwise/unset, all traffic attempts to flow out that node (like thru another gateway or whatever).
This is the secret - once you understand that ... you can have devices on your LAN which have more than one network connection, using either a combo of ETH0 and WiFi, or multiple NIC cards, or even Ehternet-to-USB adapters. So, for example. if your WiFi connection from your PI goes to your home AP/Router, you have access to both your mesh and your internet and you can "bridge" the time info without turning your PI into a gateway for others. There are obviously broader implications for this as well. I sometimes access my PI with Remote Desktop over the public interwebs and then have secure access to my Mesh with no (known) unwanted cross-over possible.
It's been an amazing adventure learning all about this terrific AREDN project, and our own little Mesh Island is shaping up slowly. Thanks very much to everyone who has supported this project. I *really* hope further development is still taking place in the pipeline.
73.
- Don - AA7AU
You are here
How to make time on your mesh!
Thu, 06/14/2018 - 15:44
#1
AA7AU
How to make time on your mesh!
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Here is another very comprehensive guide on building a GPS-based NTP server on a pi 3.
http://unixwiz.net/techtips/raspberry-pi3-gps-time.html
Ian
The other issue I ran into is it took a bit to get the software configured properly to use the real time clock (RTC) when the Internet wasn't available, and to use NTP when the Internet was. A lot of obsolete info on the web for earlier versions of the RPI's OS for the RTC. The bottom line was I wanted something flexible enough to provide accurate time when the Internet was available and reasonably accurate time when it wasn't. And something that would work if the RPI had been sitting on the shelf for awhile.
While I was at it, I used the same RPI to host a Mesh Chat server (better for numerous reasons than putting it on a node). And I made the home page of the web server display a banner at the top edge that showed the current "server time". That way anyone with access to the mesh could quickly check the time and we'd all be using the same time.
Dave
Could you share your RPi time synchronization and presentation techniques in more detail?
73,
Gordon Beattie, W2TTT
201.314.6964
So, there are two parts of this... setting up the RPI as a NTP client/server, and making that time available to humans via a web site. On the first point, here is what I did:
- I used the RPI's Ethernet connector for the connection to the node, and the WiFi connection to connect to my home LAN (and thus the Internet). The RPI by default isn't going to route between the two networks, so the RPI effectively isolates the mesh network from the Internet, while still making a NTP server (the RPI) available to the mesh network. I configure the associated node to "advertise" the web server ("TimePage") & MeshChat.
- I added the following to /etc/wpa_supplicant/wpa_supplicant.conf
- issued ifdown wlan0 and ifup wlan0 after above to establish WiFi connection to local LAN
- [alternative technique is by installing wicd-cursers which reportedly provides a CLI based GUI for discovering and configuring WiFi connections. I haven't tried this]
- Make sure you check the "disable default route" option on the associated node. That way the only default gateway the RPI will acquire from the two networks is that for the local LAN’s wireless router
- Added RTC module (ds3231 chip) purchased on Amazon. They are cheap... just make sure the packaging will fit within your case and that it includes a battery, not just a capacitor, for maintaining time.
- Use raspi-config to enable I2C module [assuming not enabled for other reasons]
- Add dtoverlay=i2c-rtc,ds3231 to /boot/config.txt file and reboot [if another chip is used, then adapt command accordingly]
- Verify correct system time and set if necessary
- Issue sudo hwclock –w command to write current system time to RTC .
- Issue sudo hwclock –r to read the current hwclock time (making sure all is working on that front)
- Run apt-get purge fake-hwclock
- Delete /etc/adjtime
- Comment out “if [-e /run/systemd/system ]; then” section (three lines) in /lib/udev/hwclock-set
- Reboot and verify system time (date) and rtc time (sudo hwclock –r) are correct.
- At this point, you should have a battery backed up clock to keep your RPI time mostly right, and when the internet is present, it will get synced to Internet time. Possibly the above could be refined a bit, but it worked for me...
The web site portion... for space I'll need to assume you know the basics of getting a web server installed (I used apache2), and adding PHP support. I don't claim any great skills in this area myself. The key point was most of the techniques I ran across were actually reporting the time of the PC accessing the webserver... NOT what I wanted. I wanted to display the web server's time. I found a script that did what I wanted here: http://www.javascriptkit.com/script/script2/servertime.shtmlnetwork={
ssid=”your_ssid”
psk=”passphrase”
}
You can put what you want on your RPI's website. In my case, it was pretty basic... there is no doubt a better way to do this, but I looked up how to do "frames" (along the way finding this is considered obsolete web technology!) and put a frame at the top edge of the page, just tall enough to have one line of text, which is configured to refresh once a second. The text simply says "Current Server Time:" followed by the date and time derived by the script noted above. The result is the time is incrementing each second at the top of the screen. The "main frame" of the web page has a scenic picture of our community, the ARRL logo, and a link to the MeshChat server (on the same RPI). Nothing fancy.
Dave
Thanks for the information. I would, however, add a cron job or something to check for NTS service on the internet and update the RTC accordingly on a reasonable interval.
73 de AL0Y
Dave
Thanks for the additional details, Dave. We did indeed follow similar paths.
For anyone else reading later, a few differences:
- I did NOT advertise the service, only the DNS name as that's all that's neceesary for other nodes to find/get NTP service from my PI;
- i did a simple NTP install on the PI, nothing fancy (running Jesse);
- We leave our Pi on 24/7 running off 12V->5V so we didn't add in the HAT/RTC hardware as we didn't think it was worth the potential battery draw;
- we do currently use the Pi WiFi as the connection out to the LAN/internet side, however we'll soon be turning off WiFi (also saves battery draw) and using a USB to Ethernet dongle for that link;
- we are configuring the GPS dongle but that will only be used if/when the internet NTP link is down - the PI3 is just fine for shorter periods of time if need be, just as along as we all agree that's the "town clock";
- I installed WordPress with a minimalist theme and am using a "DT World Clock" plug-in the provide a client-side driven clock display on the right sidebar of every page for the the thin-client (web browser);
- we have only used the very most basic graphics (like the minlmal AREDN logo) necessary on the WordPress install so as to not burn bandwidth in exchange for cute;
- like you, we provide links to our "general" (multi-homed) MeshChat as well as to a special-case separate zone for "EMT-Chat" with its primary located at the hospital node;
- I have a couple tables populated listing both Mesh node data (MAC.IP. status.links, etc) and listing our local 4 linked mountain top repeaters and a couple other non-linked machines;
- we are slowly building out the website with more "support" data etc, with a huge "status" indicator in the top-left of every page indicating what mode the Mesh etc is in right now (IOTW, don't use website unecessarily if condition RED).
It's surprising how well that little PI3 handles WordPress/Apache/Mariadb when you don't try to overload it and especially when you don't run a local browser instance or local desktop usage. It does however very nicely support XRDP for Remote Desktop access from the LAN/Internet side as needed for occasional support.
We are in the process on implementing Nagios3 (which I've running on one of the first PIs for years now) to keep a monitor on all our mesh etc etc. A bit detailed to setup/configure but install very easily as "sudo apt-get install nagios3: (IIRC).
Anyways, I just try to keep remembering that everything is a trade-off and stay focused on the mission not the optics.
Thanks again.
73,
- Don - AA7AU
addendum edit: I run Jesse NOT Stretch and will not convert to Stretch for any [known] reason - YMMV.
I only found out about "Stretch" a couple days ago... when I stumbled into the fact my RPI running OSMC at home had updated itself to Stretch. Just curious... any particular reason for your aversion to Stretch? In my limited reading on the topic, I hadn't heard of any issues, other than the usual caveats for OS upgrades about possible driver issues, etc.
Dave
Just a quick reply. Raspian is based on Debian. Each new major release of Debian is named after a new Toy Story character, hence Wheezy, Jesse, Stretch. While the PI is capable of running other flavors of Linux, such as ArchLinux as used by the excellent HamVoip system, Raspian is considered by most as the best choice for general usage for a Pi/Pi2/Pi3B (but not for a new PI3B+).
'Raspbian Stretch is the current stable release at this time. The previous release, Jessie, is classified as "OldStable" and is still being supported until June 2018, at which point it converts to LTS for security updates only.' There are very real non-backward-compatible differences between the two.
In brief, in my opinion, Stretch is the "Windows 8" of the Debian lineage. There are numerous discussions all over the interwebs comparing these, including lots of posts on how to revert from Stretch back to Jesse. I think that further discussion of Jesse vs Stretch is probably off-topic here, so I'll skip the supporting details. I just wanted to clairfy that any posts on using a PI on our Mesh refers to using Jesse, and that I do not personally recommend Stretch.
The worst part about all this is the huge amount of "help" posted (scattered) across the interwebs that is not dated, not specificied as related to a particular OS release level. not ever updated after initial post, and very confusing for someone trying to find their way thru for the use of a Raspberry PI (and lots of other stuff). There are lots of "scat for dummies" which will truly screw up your project (and your head) even though it probably was posted with good intent.
Caveat Emptor,
- Don - AA7AU
With the final paragraph of my post in mind: Jesse and ArchLinux now run fine on Pi3B+ and Stretch has matured and smoothed out some of the rough spots. The reader is suggested to seek out more up-to-date info on the above, as my 20-June-2018 is now slightly inaccurate and out-of-date.
Sure wish more of the PI stuff on the interwebs had this kind of follow-up and update.
Caveat Auditor,
- AA7AU - Don