Hi!
I would just add one more thing:
While I believe firmware is good to iterate, I would strongly argue
against reinventing the node database system. Those we really have too
many already. :-) In all possible programming languages. Especially
because it takes much more time to develop a feature-full system.
Mitar
On Wed, Jul 10, 2013 at 4:21 PM, Charles N Wyble
<charles(a)thefnf.org> wrote:
Oh no. Not another firmware project. Please work
with qmp or libremesh or
villagetelco.
I find this statement odd. In my opinion it doesn't make sense for
different mesh projects to share a firmware project. These "firmwares" are
all just OpenWRT with extra packages pre-installed and a bit of
mesh-specific default configuration... sometimes some custom web gui stuff.
Most of this will vary based on what the mesh project is trying to achieve.
New work in the form of additional features for OpenWRT should be put into
OpenWRT or released in the form of OpenWRT packages. Useful configuration
files and web guis can be shared, but will likely need to be adapted by the
different groups
Let's have a look at these projects anyway:
qmp does not support all of the devices we are using. It uses bmx6 which
as far as I can tell is based on the now-abandoned batmand, and so runs in
userland (ah!) and is layer 3. On top of that bmx6 it seems to have a
worryingly small amount of documentation. qmp has a few tools that may be
interesting, like a node map, but then again all mesh groups seem to have
their own node map and little helper tools.
libre-mesh.org is giving me a 502 bad gateway and
archive.org does not
have a copy of the site. Looking at the git repo it seems to consist of a
few make files, a bit of addition to the openwrt web gui and a bit of
configuration. It oddly installs both bmx6 _and_ batman-adv on all routers
(we have lots of 4mb flash routers. space is an issue).
villagetelco seems to be a for profit company (?). They support only
their own hardware and two models of tp-link. It bundles SIP stuff and its
goals seem to be very different from ours.
I'm sure someone who just wants an easy to deploy mesh solution and doesn't
care too much about the specifics of the firmware could be happy with these
solutions, but given our goals, basing our firmware on either of these
projects would likely set us back more than it would help.
In my opinion, the correct solution for building a mesh firmware is to
begin by identifying what the needs of the mesh project are, identify what
functionality the firmware must have in order to best fulfill those needs,
then find the best tools from OpenWRT or other mesh projects for the
required functionality and finally combine them into a custom firmware.
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh