[Battlemesh] Proposal for battlemesh v10 "testbed"

Gui Iribarren gui at altermundi.net
Tue Dec 13 21:47:53 CET 2016

Hello battlemeshers,
during a conversation on the last day of the wbmv10 recognition visit in
Vienna, while discussing the testbed plan, Simon mentioned that he
wasn't really personally interested in "battling" protocols so much (as
in the first few battlemeshes), since noone is doing crazy development
on the core routing code like in the beginning, and so there's not much
to show or see.
i.e. development is on features or edge-case optimizations that don't
really make a difference in the battlemesh results.

of course, there's also the problem of the "testbed firmware"...

So, I proposed to try something different on wbm10!

there are already out there mesh firmwares implementing each routing
protocol, being maintained every day, and so up to date with kernel,
openwrt, and routing protocol versions, etc

why not use those firmwares?
i.e. qMp, Gluon, LibreMesh, what else?

so for example, on day 1 of battlemesh, qMp devs flash everything with
qMp firm,
everything works out of the box since they care about that every day of
the year :)
qMp devs can explain a bit the features, routing architecture, etc
and it runs bmx7 so Axel can even run tests on his protocol that day

next day, gluon devs flash a gluon community firmware (could be
something done specifically for the event, or just extending an actual
again, everything works out of the box, and has a sensible configuration
of batman-adv
gluon devs can explain features, config wizard, etc
batman-adv devs can run tests on their protocol that day

next day, libremesh devs flash libremesh... rinse and repeat

not only minimizes chances of total failure,
but also shifts the focus of attention to actual implementations (mesh
firmwares), where a big part of the development is happening.

what would be a good candidate of a firmware being used/maintained in
the wild, that runs OLSR and/or OLSR2?



More information about the Battlemesh mailing list