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

     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.

     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.

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.

In the downloads folder for both Linksys and UBNT, there is an experimental software link that includes version 3.0.0 Beta.

I have put it on my mesh network here in Waco with good results.  It appears to fix or mask the errors in 1.1.2.  I have over 20 nodes up and running and they are maintaining connections.  The OLSR crashes are minimized and the watchdog is bringing it back up when it does crash.

Who else is using it and what have been your results?

Clint, AE5CA

All,

I have both a Linksys WRT54g v-2 and a Linksys WRT54g v-3 routers initially loaded with and  running version 1.1.2 but on both of those routers the full html page for the 'status' (initial load page) is incomplete. When I locally connect to the MESH using the proper IP/port I get the normal redirecting link then the Status page for the router starts to load but then spins on until it times out. It displays the nodes name and shows the command buttons but when I view the html source behind it the code is incomplete. I used a good version 1.1.2 Linksys WRT54g v-2 MESH node router to compare the html and on the two mentioned the code stops midway down the listing. If I select the WiFi Scan button it works properly but none of the others work at all.

I have tried to use the update .trx file to reload things but it results in the same condition after I reconfigure the nodes. I think that the update file does not restore the files in the /www/cgi-bin folder when it is used and I can not reload the initial 1.1.2 .bin file using the Update tool on the Administrator page.

Any help to get these running again locally would be a great help.

BTW, I can access and modify the node Setup pages remotely from another node with connected PC and this is true for both the routers I am having this local issue with.

Thanks,

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

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.

See:

http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti

Most common error I've seen is using the config import box instead of the firmware import box.  The error text would go a long way rather than everyone guessing.

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.

I've demoed voip a few times.

Connect the phones to the LAN port of the nodes. Assumption is default Lan-direct mode (not lan-nat, but this also can work) and that a voip phone will use dhcp by default to obtain on IP address. Go into setup for "reserved addresses". reserve the IP address to the phone and record it's IP address. This is an IP address known on the mesh by all nodes and hosts to correctly route. Setup memory IP dial on each phone and call away. Optionally, on the same setup screen, add the "advertised service" that you have a Voip phone. Other mesh'ers will know what IP address they can call you with. Others may be able to comment on this specific voip phone.

Also Don, KE6BXT, posted a video on this website showing the set up of other voip devices to take a look at as well.

Great pic!

Joe AE6XE  PPSEL IFR  

Two items come to mind.

One:

is this a BulletM2HP or an earlier model?  The prior models do not have enough memory to load BBHN and are not supported. 

Two:

Are you using the bullet "factory" .bin file or the "sysupgrade" .bin file?  For a new Bullet with AirOS on it you need the "factory" .bin file. The "sysupgrade" is for devices that have been previously flashed. 

Clint, AE5CA

Solved:

Set to 1 port direct and turned port forwarding off on the Bullet

Connected to WAN port on router and turned port forwarding on on the router.

Also make sure your service uses the reserved port name, not your mesh name.

JJ

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.