Will the ssid remain the same with this fork, and what are your thoughts on future compatibility with bbhn? Is that a primary goal?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
The default SSID has changed (as listed in the operational notes) http://www.aredn.org/content/operational-notes-aredn-302
The default SSID is now AREDN-20-v3, however one can very easily (and likely will want to) change that to BroadbandHamnet to match the default SSID and to be part of an existing network.
As for compatibility I wouldn't say its the primary goal, even though all of us involved at this time have a large commitment with all the work we have put into BBHN the mission of this group is to build a package that is highly reliable and and provide the tools so the solution can be used not just for smaller adhoc setups but also as part of larger permanent setups (which have different traffic concerns than just adhoc networks would) with a primary goal of being able to work in an Emcom situation when it will be needed most.
I'm sure when a subject comes up that would require a protocol version change (a jump from v3 to v4 causing the software to become 4.x.x) it will be highly discussed before any decision is made. Compatibility with existing networks has always been a subject that has been talked about greatly and has never been a "Oh lets jump the version" discussion, its always been much more in depth to is the feature worth doing, can it wait till later, etc
In addition since we have an open development system where all of changes are done in the open and can be seen as make them any other groups whom may working for compatibility can very easily see and prepare for any changes well before the version makes it out in production networks.
Could you check that link? It's throwing a 404.
Sorry about that, an extra character got added to the end of the link. I've corrected the link in my original post.
I've been asking why the SSID got changed, and I'm still confused. I keep hearing about a code fork, but I haven't found anything that's actually incompatible between AREDN and BroadbandHamnet. Merely changing the SSID on a Ubiquity running BBHN was sufficient to get it to talk to some AREDN nodes, and my own ports of olsrd to general purpose Linux (x86, Raspberry Pi) interoperate just fine with both over Ethernet and WiFi.
So why was the SSID changed? I don't really want to use the G-word (gratuitous) but I'm finding it hard to avoid. If we're serious about emergency communications, this is exactly the sort of thing you want to avoid -- the less (re)configuration the better.
A large reason for it was changed was because of an insistence by the BBHN team as the breakup occurred that they wanted the program to have no relationship to BBHN as noted above.
Honestly I see most networks moving to AREDN names as BBHN is more of a tinkering network and AREDN is more intended for stable long term deployment it's become an unintended advantage (at least locally where I'm at) and will become even more so as we focus on adding Emcom features to the solution.
We were originally planning on developing for BBHN but the relationship broke down fast so we are where we are now.
Quite frankly, that seems downright silly. Unless they actually trademarked the term "BroadbandHamnet" and got an injunction against your using it in an SSID, they have no control over your use of it. (But I'm not an attorney).
I do not understand the nature of the conflict here, and I'm not sure I care. A year ago, I was diagnosed with lymphoma. I went through treatment, and although I'm in complete remission this one has a tendency to come back so I don't know how long I have. So the very last thing I want to do is to waste time on yet another internecine pissing contest; I've wasted far too much of my life on them already. I'm willing to help out but if I can't avoid getting caught up in the politics, I'm gone. Life is too short.
I don't understand the distinction between "tinkering" and "stable deployment" as you have to do the former before you can even think about doing the latter. I don't get the impression that this stuff is very widely used as yet, nor do I see that everything has been done technically to make the system as robust and easy to use as it should be for a "stable deployment". That takes time and experience.
So it seems to me there's plenty of work to do and plenty of credit to go around for those who do it, and forks and splits seem rather pointless.
yes, it is silly. https://trademarks.justia.com/865/42/broadband-86542283.html and in the past. No politics to get caught up in, we're moving forward. Creating conflict by changing SSID back would not be prudent at this point, should this be what you are suggesting.
In regards to "stable deployment". One of the topics we have been working through, when moving UI to Luci, is that we could have a very stable mature solution that enables a 'tinkerer' to change a node in such a way that it is not fully compatible with other nodes and potentially destructive to a mesh network under the purpose of emcomm incident support. Not really an early adopter technology to mature technology crossing the chasm issue--we're another bowling pin of applying mature technology.
Consequently, what exactly does it mean to make something "easy to use" for our purpose. Does it mean no one can ever shot them self or the 'network' in the foot--locked down? Does it mean a node admin can readily make any desired change and not, e.g. have to know linux and netfilter/iptables? Somewhere in the middle?
Joe AE6XE
That appears to be an application, not a grant. Also, it's my understanding that trademarks cannot be "functional". Since an SSID is most definitely functional (if you don't set the right one, it won't function!) it would not qualify as a trademark. At least not as an SSID.
Inasmuch as nobody around here has even bothered to change their SSID to AREDN in nearly a month, and the network is still down as a result, I wouldn't say it's too late.
Quite frankly, I think you have a very long way to go before you'll have what could be called a "stable deployment". It's fine to make that a goal, just as it's fine to provide reliable emergency communications, but I see many architectural and implementation problems yet to be addressed. I don't mean to demean the developers' skills in any way, it's just that ad-hoc networking is a very hard problem that has occupied the attention of many skilled researchers for a long time. Many questions can only be answered with a lot of operational experience, and that necessarily takes time. It's still not clear that a proactive routing protocol such as OLSR is always best, as it has both advantages and disadvantages compared to reactive protocols that build routes as needed. Especially as the network grows. (In the early days of the IETF, a very common refrain was "will it scale"?)
Even the OLSR protocol on which you've based the network is still considered experimental after having been published as an RFC over 11 years ago. Its replacement, OLSRv2, is only a proposed standard, and the IETF explicitly requires operational experience before something can advance toward full standard. A premature emphasis on "stability" can make it very difficult to reverse what turn out in hindsight to have been poor decisions.
By "easy to use", I am talking mainly about ease of configuration. I have long felt that the very best user interface is the one that doesn't need to even exist because the system handles it automatically. A simple example is the retransmission timeout setting in the original AX.25, which had to be set manually. TCP measures the round trip time of a network path and sets the timeout automatically. Not only does this avoid a manual setting, but it works better because it adapts to changes.
If some sort of user interface is still required, carefully chosen defaults should be provided that will work in the great majority of cases. Again, these may only become apparent after a lot of operational experience.
This still being ham radio, I think it's important to facilitate experimentation even if that causes problems from time to time. You can certainly add features to make it harder to cause trouble by accident, but you'll never be able to stop someone determined to cause mischief. Even cryptographic authentication won't stop jamming, for example.
Way back when I was writing and debugging my TCP/IP stack, we often stumbled into problems brought out by random experimentation that became obvious only in hindsight. This made me a strong early believer in what are now the widely accepted tenets of the open source movement, e.g., with enough eyeballs, all bugs become shallow. In the beginning things may seem much less stable than they would be with a more locked-down approach, but ultimately this is the only real way to get the robust, stable system you're after.
We've strayed a bit from the original post.