I am ready to announce today that I have had success creating a stratum-1 server supplying time to a none internet connected mesh. In a nut shell,

A GPS unit was installed on a Raspberry Pi taking a time signal from the stratum-0 satalites' signals.

Then the computer was set up to become an NTP server.

Then a DHCP server was install on the same computer to provide an address to the WAN port of the node.

Finally, a DNS server was also install on the same computer to create an address reference from the US pool servers to the Raspberry Pi.

Plugging the computer into the WAN port and being patient while each node makes a query to the gateway, they will set their clocks to the GPS time. This also works on the Ubiqitie's through a Linksys node.

It works and has been tested in the field.

How did you tell the other nodes to query you for the time?

I have a linux box on the air, people can ssh/http to the box ok. I know how to setup ntpd (have done it many times before) but how do you advertise the service for other nodes to discover it?

Are you stating it is a: Mesh Gateway [x]

but it really isn't hanging off the internet??

Once the node that the Pi is connected to through the WAN port is up an going, I make sure that node with the Pi has the "Gateway" box checked.

The other nodes are already set up to query the internet for the time, so when they join the mesh they find the gateway to the Internet. Then their NTP client sends a request for the time. Since the node software is already setup to make the NTP query, no services need to be advertised.

Now this is not a real internet connection in the way you would think of it. But all the nodes can send the NTP client time request though to it. The key to the success of this configuration is the DNS server on the Pi. You could also set up your Linux box to do the same. Just add the additional services and configurations to it. Then properly connect to the WAN port of a node.

Yes, I can take it into the field and it does 'just work'. But there is a lot of setup to do to get to that point. But once it is done, it is done.

Everything does fit on a Pi. The GPS unit is designed to work on the Pi's IO pins. So I did not have to deal with USB issues. But it still was a lot of work setting up the software to access the GPS time signal. The rest of the software for the other services was a lot easier in comparison. It made for a really concise box. The only cords are the power cords to the node and the Pi. Another one goes from the Ethernet port of the Pi to the WAN port of the node.

Note: this critique written assuming all hams of the mesh have not met and agreed that a meshgw node will never be used , if that agreement is in place the below only partially relevant (extra traffic and delays)

As a network engineer I see this as a gross abuse of the meshgw feature and can cause numerous problems in the long run.

One example is now your increasing delay times possibly on DNS, your putting a lot of random traffic on the mesh that will just be denied several hops down stream ( wasting bandwidth)!etc. Throwing dns queries out that will get no useable results etc.

And once a mesh node with real gateway access comes along you will be corrupting that gateways ability to serve.

Please make sure you understand just exactly what you have done to the mesh if you use this feature 

This especially true since time on a node is more a luxury than an actual technical need.

AD7QF, I'm trying to figure out when I'll have time to build one of these. Is there a section on the website you would be willing to post the config files, scripts, instructions for others to build?

If I understand your design correctly, other nodes that use this NTP-gps node as the default gateway (because it is lowest link cost to access) would then not have access to the internet should other gateways exist on the mesh. This issue only becomes significant in the scenario where it is desirable to connect off/on to the internet and be self sufficient with ntp clock. For example in normal mode our mesh in orange county is connected to the internet. But if we went into 'incident' mode, we may likely disconnect from the internet, reboot nodes, etc. So how to make this off-the-grid ntp server independent of the internet-gateway connection? (as an additional option, not a replacement?)

Would we turn off the Pi DHCP server and become a DHCP client, connect the Pi to the LAN port of a node, then advertise this as a service to the mesh. The admins of the mesh could edit ntpclient on each node with a search path of the Pi mesh 10.x.x.x address, then fail over to internet ntp IP address?  maybe we need a mesh ntp finder script for a node.

I have found several articles on building a time server on the internet and I will probably build one in the near future. In the mean time, I have a Linux computer attached to my QTH node. Since this node has internet access, the computer has access to the internet through the node. I do not check mesh gateway because I do not want to provide internet to my entire mesh. 

By setting up the computer to serve out the time it receives from the pool servers,  I have a time server on my LAN. This computer hosts a number of sevices including web, email, asterisk and a file server. All I have to do is reserve an ip for the computer in the setup section of the web interface. 

On a remote node editing the ntsclient file to point to my server on the mesh provides the time to those nodes. 

Any NTP traffic is on the mesh and my server already had the time. 

I could plug an dedicated NTP server into my nodes LAN and advertise it to the mesh. Manually updating the ntpclient settings on each node is the hard part.  

I would not want my time server to be visible from the internet. I don't want it on the WAN interface.

Clint, AE5CA

In this geo area no one has made a gateway, as of yet, to the Internet, and are not likely to. We do mostly ad hoc field setups for event support, field day, etc.

The purpose and assumption is that there is no Internet gateway. In addition, both the node and DHCP server offer up Google name server addresses for failed resolutions. Nothing unusual about that. Again I repeat, if an Internet gateway exists then there is no need for this device.

My experience is that mesh are being set up without a gateway to the outside Internet. And you will agree that random times are seen across such a mesh from each node. Such chaos can not be tolerated on the Internet. There is some software that will choke with inconsistent timings.

Having an actual Internet connection is a luxury, and may not be possible. Having the correct time "can" become a technical need. We ordinarily do not see the need with the simple services currently being used. But as we become more sophisticated in our use of BBHN mesh then what you call a luxury will become a critical technical need.

With this understanding, I put forth this as one possible solution. Part of it's elegance is that the operators of the other nodes need not understand or configure their devices to take advantage of this service. That is until the BBHN software is modified to allow better control of the time settings, such an appliance it useful.

     I have not completely codified the processes yet, as some more experimentation is to be done to satisfy my curiosity. Such as, working with additional GPS devices. Currently this is dependent on a single vendor. At such time as I do, then step by step instructions can be written. Also, by then I will have read all the critiques posted here and evaluated their worth.

     As you see in my previous posting, this appliance has it's greatest worth when no other connection is available. A very real and frequent situation. If a current Internet connection becomes lost, then would be the time to plug this appliance into a WAN port.

     As currently coded, the BBHN node software is not set up for alternatives. Until that is changed, this is the most eloquent and simple solution. I have seen in the wish list items addressing the need for better time controls.

     As you said, " Manually updating the ntpclient settings on each node is the hard part."

     This may not be a solution for everybody, it was never meant to be. But it is eloquent and simple once it is put together. Part of that is that it does not require any modification of other nodes. It is also a boon to those that would be daunted in going in on the command line of a BBHN node to make modifications from there.

     As I said before. A great appliance in the correct situations.

Ok, as long as you understanding (and anyone reading this in the future) understand the limits of the suggestion that is all I wanted to make clear.

BTW: Patches are welcomed (GPLv3) for adding features that fit a need such as picking up the time from a different node that is advertised, sorting through them to find a valid one, etc) Some features make it in quicker when someone whom personally really needs it and is vested in its outcome is working on it (Ubiquiti in my case.)