I wonder if the Mikrotik line is under consideration as an alternate? They seem to make several UBNT clones which run, without modification, on the "superchannels" and they have a built-in mesh mode of operation (not OLSR though). On another forum I visit, one guy likes to sign "anything is possible if you don't know what you are talking about". So, in that spirit, I would say that it might be possible to put OLSR into a Mikrotik and configure it to do a hamnet mesh without having to replace the firmware. But, since the Mikrotik stuff will run Open-WRT (for example ) RB911/912), the firmware flash approach should be straightforward for someone "skilled in the art".
Regards
Ken
Last time we looked, mikrotik didn't have sysupgrade support (in-place updating) in OpenWRT which is critical for EMCOMM deploys (IMHO).
this is all new stuff to me. If I understand, the prime requirement for sysupdate is so you can update the software without wiping your configuration information.
I did find a write-up of a generic sysupdate procedure in OpenWrt:
http://wiki.openwrt.org/doc/howto/generic.sysupgrade
seems like you could cobble something together, if it does not exist. (The MikroTik factory GUI has this kind of thing as a standard menu item - i.e., store a backup file before the upgrade and reload the config immediately following the next re-boot - the one after the upgrade).
I would point out that the UBNT sysupgrade does not actually satisfy the requirement above. I did the factory install of the stable release and then did the upgrade to the latest version. But the upgrade wiped out my call sign, password and probably other user config information.
We have a patch on the beta page that is intended to be released with 3.15.1.0 when it is released that will fully support over the air upgrades. 3.0.2 has to have the patch applies to it first but after that it should upgrade. We have been tweaking it as we go along and just waiting for Beta 3 to release a new rendition.
As for Microtik im not fully aware of the issue, it sounds like from what I have read it is something in boot loader that prevents it from being done from a running operating system, to my knowledge OpenWRT has tried and so far not been successfull in making it work.
Beyond that flashing them the first time is also a pain and may not be for most inexperienced users as it requires manual intervention currently above and beyond what Ubiquiti needs. It is certainly nice hardware, it's just the time/reward hasn't yet been there with all the "known" issues of the process. If somone could eliminate or mititgate these issues they would be much closer for consideration.
Also a minor item (as in it will become less of an issue in time) last I looked Microtik was going through a refresh similar to XW hardware and as such OpenWRT was spotty on device support waiting for the new hardware to get more bench time and as such Microtik wasn't at that time going to be useable. I haven't looked in past 2 months on that however to see the status if it's improved or not.
OK on the OTA upgrade. That is great for remote locations.
Back to MikroTik: doing the upgrade while the system is running seems like a bit of overkill. You are going to do a re-boot at the end of the upgrade anyway, so what is an extra couple minutes of down time ....
Anyhow, before letting this die altogether, let me go back to the alternate idea of using the base MikroTik software to run a hamnet mesh. I would point to the raspberry pi version of mesh software. Scott Kidder produced a small program that implements the hamnet mesh using any old USB wireless adapter that can run in "ad hoc" mode. I imagine that some of the stuff he installs is already present in MikroTik (and any router with a web-based GUI). Could the needed bits for hamnet mesh be added to a standard MikroTik install, without the need for any re-flashing? Alternately (this question may belong elsewhere) can a MikroTik wireless router be made to appear to be just a wireless adapter (that happens to run on channel -2)?
Ken
"while the system is running" meaning the flashing doesn't take place from inside a functional system so that we can than later write the settings back to the device so that when the device reboots with the new OS it has the settings it needs to come up and be a part of the existing network (aka the core concept of OTA being no trip to the mountain needed to upload a config file backup)
To my knowledge Microtik devices (like Ubiquiti)do not support ADHOC mode in their stock operating system which is a core requirement to be a Mesh Node. Could they be used as backhauls by specially trained users, probably, but they couldn't be used to make a full mesh without ADHOC.
As for Scott's program I've seen it in the past. We do not recommend using Pi's as mesh nodes because of of all the logistics around putting them outdoors in a reliable way with weather proofing, power feeds, etc it just doesn't seem to make sense in an EMCOMM deployment model. One also has the trouble thay most USB Dongles are single chain devices as well which decrease performance.
OK - I *promise* I am done with this topic.
So the answer is: that MikroTik does not support ad-hoc mode (they have their own mesh and WDS which can do something similar to hamnet mesh). I am guessing it is a deliberate decision to not support it, rather than an oversight.
Because the MicroTik wireless driver does not support ad hoc, you need to wipe out their software with something like DDWRT and there are some issues with doing updates.
= = =
The last bit - I am not advocating MESH-PI as a "production system" for an Emergency Network. I am just saying that it was an eye-opener for me - you can take the standard features of Linux networking, plus open-source OLSR and plug in a wireless adapter that supports ad hoc mode and you have a 'hamnet type' of mesh network node. In principle you don't need Open WRT. There is less black magic in it than I had originally supposed ;-)
Thanks everybody for the responses.
SK
Ken
As Conrad said, that is exactly what the "OTA update" patch is for on the experimental downloads page.