Trip to the Wireless Battle of the Mesh v7 Leipzig
Last week on Wednesday we took the bus from Weimar to Leipzig to the BattleMesh. An international convention with people working on wireless mesh routing protocols.
On late afternoon we arrived at Sublab. The hack-space in Weimar – ‘Maschinenraum’ – has a strong connection to the Sublab in Leipzig. One of the initiatiors of the Sublab was once part of the group of pioneers tinkering around with wireless technologies and free and open software years ago in Weimar.
So we know the Sublab from its early days on and tried to visit the space at least once a year.
It was nice to see the space packed with so many international and very skilled people. Everybody was sharing ideas and answered a lot of questions we had regarding our google summer of code project.
About want we want to build and acomplished
Like many others we see the need for a remote monitoring and administration interface for WiFi nodes in a mesh network. A single person or a group have access (ssh keyring) to a nodes device statistics to monitor their health. The ‘admin’ can change config values or even re-flash a node or a group of nodes without the need to connect to every single router manually.
In a first draft we collected as many different device statistics as possible, like hostname, openwrt-version, hardware-model, uptime, memory etc. (Referred to as system data)
Configuration and statistics of network interfaces are another big blob of data we want to collect.
At the beginning we saw that many of our questions can be aswered via ‘uci’ calls, but some can not. We noticed that we can get native json output from network statistics, but for the rest of the data of interest we were unable to build proper json output. This was because of the missing support of json via jshn.sh / jshn and the complexity of Lua.
However while talking to the partitians of the BattleMash we were told about ubus
. After discovering the abstraction caracteristic we decided to make as much ubus calls and avoid using community-specific shell scripts. All collected data will be processed by the monitoring-app writen in node.js which can run directly on supported routers or on a server or desktop pc.
We had a look at a lot of differnt software for monitoring a wireless community network, like http://www.weimarnetz.de/monitoring/, http://db.leipzig.freifunk.net/, http://blog.freifunk.net/tags/nodeshot
We also checked out some general network monitoring tools like rrdtool, bmon, vstat, mrtg and smokeping.
Right now we’re prototyping authification and establish data streams via ssh and ubus from monitoring server to
destinated client. On the other hand we’re prototyping the interface of the app. It will be based around a visual representation of conneced nodes. Nodes with monitoring access provide additional data. Managed nodes allow for config changes and re-flashes directly from the apps interface. (check out the mockup)# Freifunk monitoring and administration panel.