Is there a file somewhere that shows what changes where made between versions? I don't understand why version 1.1.x is not compatible with 1.0.x?? I did a test upgrade and all of a sudden the 1.0.x nodes disappeared? There is no backward compatability?  I don't understand why there is no compatability, did OLSR change or some other underlying way traffic is passed? A CHANGELOG would be nice as well as some kind of FAQ.

This is potentially painful for larger networks. Is there a FAQ or Doc on how to upgrade a network say with 25 or 50 nodes? Would you have to travel to each node site and do one bye one or can you perform upgrades over the mesh with the farthest points first working your way back? From what I've read in past posts it seems you have to be at the site or at least in wifi range to get to the node you are upgrading with a .trx file?!

73 de KF7PSM

Well not 50 that was as an example, but we have about 10 nodes up now on one side of the valley and are slowly building around the valley. Problem is some nodes are managed by the same OP who got permission to be at some QTH's tower. I'm sure the owner of the QTH doesn't want to be bothered with "CAN YOU UPGRADE MY NODE" requests so if a Op has 5 or 6 of these sites, it becomes a pain to drive out and upgrade. I thought possibly it could be done remotely by upgrading the furthest point out first but after reading the threads it seems that is not possible as the unit defaults to an access point. Maybe that is something that can be discussed for future versions. I see these networks getting larger and larger with the release of 5.8Ghz and 3.4Ghz nodes and at some point upgrading would be nice.

THANKS FOR THE QUICK REPLY!

73 de KF7PSM Peter

Peter,

I totally get it... and we have discussed this issue recently.  Unfortunately it's not here yet.  Thanks for your thoughts on the subject and we hope to be able to include such a feature in the future.

Andre, K6AH

I think loss of interoperability is a big blow to the future of mesh networking. I can't imagine that all the nets in the world will continually upgrade to the next version. So for travelers, like many of us, it will be a big issue. I intended to run a node as I drove from Maine to AZ this fall. I won't be in any one place long enough to re-flash my routers every time I change networks. 

I have run a number of repeaters in places like Maine, where access is a sometimes thing. Many of the sites are a hard trip by snow machine or helicopter. Get a ride up when the commercial guy has a problem. Not something that will happen for a software change. We are in the process of building a link which will use a hardened military site as one part of the hop. Not an easy place to access when you are trying to keep a low profile.  

And what happens with VPN attached systems? I assume they would need the same version to work together. I have been considering hosting a VPN server at QuartzFest15 (or perhaps QF16--17?) with a link (via firewall) to the outside world. You could leave your home network running and VPN to it through our server. For those that might not know, QuartzFest is a week long hamfest in the desert just south of Quartzsite AZ in late January. Last year I think some 600+ hams attended.

 Other networks could VPN to us during QFnn and attend virtually. In time I envision one of those "Personna Robots" wandering about QF19, attending the seminars, run by a ham in Idaho..or Brazil...

 Obviously the version changes are considered a necessity. Nobody would go to that much trouble, rewriting the software unless it was necessary. I just wanted to voice some issues that hopefully will hide in your mind as you continue developing software for what I consider to be the next big thing in amateur radio.

Ron, N1AHH.

 PS. We will be running a mesh network at QuartzFest 15 this January. Hopefully with a slew of nodes and many services. It will be a great opportunity for us to learn about dense networking, solar operation and general messing about with networks. Interoperability is already an issue.

Well let me address the quick part of this first. Upgrading nodes,  I'll admit is currently not the easiest of process and not the most feasible remotely (it is actually doable though via various methods since it comes up in a AP mode still)  You will want to keep an eye on BBHN->ticket:54 for this.  Your not alone on that issue, its been voiced by the beta team as well (whom each has probably done more upgrades than any other group around)  that it is something we need to add. It is also an issue that affects me as one of my nodes is in limited access with a second also planned. The ticket hasn't had much progress due to  several other priority tickets in recent months but it is on the list of things we want to be seen done.  Hopefully it will be possible in the nearer future to get those nodes upgrades without any direct interaction. 

Compatibility, now that is a deep subject.  You are right that it creates its own issues jumping versions, and it is not taken lightly. Networks take time to upgrade and planning to do, The choice to go to V2 was done based on needs seen and as many of those needs that would need to jump a version were put in at the time of the build (compile enough changes to justify the version jump.) Some of those needs might not stick out at first, but as we plan ahead for networks to be bigger we have to be ahead of the curve.

Version 3 was in no way on the roadmap for this soon (read as: I had zero items on my personal roadmap that could justify being the cause of a version jump.)  Without being binding (life changes as we move along)  that probably meant I hope at least another 12+ months before the subject even would arise.  Version 3 is ultimately a patch set, we found issues in the 1.1.x build that we think are going to take a couple months to fix, and it just happens it was in one of the parts that was added as a feature (but wasn't the only protocol changing feature added so we can't just roll back to V1)  It was a difficult choice to come out with V3, but was made based on the general appearance that not many networks had fully adopted V2 yet, and that the issues were so severe we needed to provide a new working version.   The goal was to fix the problem and get a release out without a version jump, that didn't pan out and the decisions tree basically got to where we had to make the decisions to pull a set of code that appeared to be a large part of the issues, and get a  more stable release out.

I can attest that a  large number of man hours were put in by the beta team members to find the root cause of why we are having the issues we are having.  I wish I could say from the dev side that we were already able to solve all the problems based on their feedback but we havent.  They have given us significant amounts of detail on the matter and worked with us to make sure we collected all the information we believe could get us  to fix the issue and it puts us where we just have to dig through and find the  lines of code that cause issue.

So in closing, you have a perfectly valid point, and it is absolutely fair to be commented on, especially from the forward thinking mindset you appear to have on the subject.