Use of Raspberry Pi3 as MeshWebServer

Note: If were going to continue discussing this we might want to open a new forum thread as we have really moved away from the original topic of "Use of Raspberry Pi3 as MeshWebServer" which means this discussion is become very much buried where it will not be of much use to other users.

"If NTP is only for display purposes then why the heck is it there?"
A fair question,   Part of this is historical, and this has to be traced back into our history under the BBHN name.  Back under those days (and even a bit under AREDN a bit with MeshChat for example) it was considered acceptable to run additional software on a node. Protocol Version 0 and protocol Version 2 might of had some minor TIME affinity related to the message signature algorithm, but it didn't have to have accurate time but it could benefit from it. Some of these additional software that were historically talked about running on  node could very much need time for their purposes even though they were never officially supported as part of the project.  This history continues to spill over and the view of the devices continues to adjust as time continues, but a lot of historical  'its always been' and "it may still some day be needed"  remains.    Just because today we have nothing onboard the node that is time decadent doesn't mean we won't have a new feature that is somehow time dependent tomorrow.  A Feature Request to remove the capability hasn't ever been submitted so the core group hasn't ever discussed if it comes out.  I can't say if it would be taken out or not if requested as i could see arguments for and against but ultimately it makes everyone happy to see accurate time on their node so a NTP server setting has to stick around though equaly (untill something becomes time dependet) it a similar level could be served for a large majority of users by the team just removing the date/tiime fields from the GUI and no one would have a clue about it but that didn't get much traction at the time I had mentioned it.

"That's why I put up our own NTP server. We are a mesh *island* and do not use tunnels or direct internet connections. The only way we inter-connect is thru a device like our PI as described above"
Even then I would expect the timeserver to be fairly accurate, not knowing your exact layout, timeserver daemons know to degrade themselves  if they loose their sync source. GPS Synced systems will degree to local clock and indicate as such inside their protocol and may even refuse to serve time.  Of course its always possible to setup a timeserver that syncs from its local clock w/o syncing it to a secondary source (GPS, GPSDO, Rubidium, etc) in which case you could have error yes.  Ultimatley this sort of reliability and accuracy would be up to the timeserver admin to configure in their system. A node will always have to trust its getting valid time data as it can not indepdnetly verify it.  How accurate you want that time source to be is a choice of the local network. I know some groups that will be happy with +/- several minutes time across their network, and I know some groups (maybe not so much in ham but in the IT world where I work its a lot more valid) where +/-100ms is acceptable only as long as the clock is in the process of skewing to accurate to the nanosecond. 

"I did run across a help file which seemed to imply that NTP *was* checked and kept current on the mesh." Its possible we have some bad documention somewhere,  if you see it a bugfix ticket is always appreciated so we can track it down. A lot of code went in before I even started working with it under BBHN,   a lot of code then went in after I started working with it but before I was able to get a formal code review process in place.  During both those windows small items like documentation could have been easily overlooked. Its very easy to get focused on one small part and forget about the rest not realizing it exists.. 

"Was the original default NTP server setup as blank?"  The original should be us.pool.ntp.org

I'll note until the 3.16.1.x release versions this wasn't even a setting a user could change, it was set in the backend and wasn't a suer choice. I can with hindsight reading your message see how someone may think a timeserver actually serves a purpose to a node for some functional reason based on how that page is laid out.

"We're struggling with  used M2 Bullets (all we could afford) and inexpensive antennas and trying to make our proof-of-concept AREDN network something to demo to our local support community and upon which to base future funding requests."

I can understand trying to work within what you have set as a budget, honestly though the bullet is one of those devices that is just a shot in the foot.  Depending what you mean cheap antennas (for example those yagi's where the square boom is 50% of the width) you could be ending up with a dummy load for an antennas or higher cost than it would of been to just wait a little bit and go with a NanoStation or some other setup. There is a good article from Clint who I worked with back in the BBHN days http://ae5ca.com/your-first-bbhn-node-should-be-a-nanostationm2/ where much like him I thought the bullets would be great devices and I too found out while they were better than the WRT54's they were nothign compared to the NanoStations for both ease, cost, and quality.   In my experience from looking at various deployments for the Proof of Concept its really important to go with good solid gear vs what is cheaper.   You can always bring people in later with some of the less ideal gear, but if you can't get the concept to work  you loose the interest of individuals and may never get off the ground.   I've heard of this with WRT54's from back in the day, they got the community talking, but they were so limited they would actually push people away from trying got setup a mesh.     To do a good POC for my city and get them interested I invested in a Rocket and Sector antenna, it wasn't cheap but it created a reliable network that got users on, the network has grown for my city to the point where once my node was core critical that now it can drop off in a failure and the network has enough redundancy to continue on without it..  This however took having a strong presence that users could reliable connect into  first to get them momentum growing.

"However this seems like the problem where the mesh remembers forever an abandoned tactical node name without rechecking it until that node drops off-network for a time-out, instead of reverifying the tactical name"  This is a known flaw, I put some partial fixes in  under a previous version but they were found not to fix everything.  Unfortunately the team is small there is limited time to track down and go after issues. I find a lot of times my codeveloreps seem to want to hit fancy and new feature vs take time to work on a known problem and seem to want to focus on  'how can I get some code in quickly even if it has flaw and we can fix them some undetermined time later" (A heated discussion item on our last held weekly call on the 8th)  And unfortunately sometimes even larger issues come up that force us to move away from dealing with the more obvious items (like this flaw) to dealing with them for longer term stability.  Its a juggeling match of resources and enthusiasm that is hard to fulfill every desire.


"Neither does having every node which does not have an NTP connection available just keep pinging out into the darkness forever."  From a technical standpoint I wouldn't expect this to be much different from just blindly checking for NTP server. Getting very technical,  they both use UDP packets.  ECHO Packets have a shorter lifetime vs a NTP packet which means less socket open time which means less exposure and less resource consumption.  In the case of  a DNS name like the default us.pool.ntp.org  unless one has internet access the domain name won't even resolve which means a ping will exit out immediately.  The same is true of a hostname based on the local mesh, until the node has the hostname in its data file its not going to even send any packets off the node so its not like any extra traffic. This also holds ture to a static IP unless there is some route to that IP or a default (internet) route its not going to generate any packets off node anyways (they will all be dropped inside the kernel)   Why the code was written this way originally I don't know, I believe this was common of  OpenWRT firmware at the time the project (under the BBHN name) was started and its held on, I'm not sure if its still the common method or not.  Noting that embedded routers often do things much differently than a desktop would because of how they operate in much more confined environments.  Could there be better ways to do it, possibly.  Without a deep technical dive onto every line of code I can't say for sure if this is actually that bad of a method to deal with it  since the NTPClient is a very simple application it may not handle non resolvable hosts and packet loss as well as a ping could can as just one example of maybe why it was done this way.