Push, data authentication and Babel support

Nodewatcher v3 has gained multiple features as well as stabilization bugfixes in the last months.

We are now running the latest development branch of nodewatcher v3 in parallel with the old version. Imports of nodewatcher v2 data are done regularly in order to test out new fixes and features. Due to having a live version deployed in an actual network, we have found and fixed several bugs related to firmware generation and monitoring.

It is now possible to automatically configure STA interfaces on nodes based on the target AP interfaces to which a node should be connecting. While configuring an interface in station mode, the user may simply select the target node instead of manually inputting connection parameters. This enables a better overview of point-to-point links used by the backbone and ensures that the configuration is automatically updated on all the client nodes. Virtual interface names of wifi devices have now been made more human readable (they are now ap0, mesh0, sta0, etc. instead of the previous somewhat more cryptic names). Due to testing, device descriptors for mutliple devices, and thus support for these devices, have been greatly improved. Definition of community network specific default configuration has been simplfied and the module that automatically generates forms for configuration models has been refactored in order to make it simpler.

Our OpenWrt telemetry agent has gained support for pushing data to a remote server in addition to the data being pulled from it. This means that the nodewatcher instance now no longer needs to have direct connectivity to the nodes as the nodes may also push data to it. We have also added support for authentication of reported telemetry data, using extensible authentication mechanisms (currently, there is only one based on public key cryptography). When using push, nodes may also authenticate the server using public key pinning. In order to support some ESP8266-based sensor devices, a simple Lua library has been developed for pushing sensor data to nodewatcher.

We now also have support for the Babel routing protocol in addition to the previously used OLSR. This includes device configuration and topology reporting from the nodes (since Babel is a distance-vector protocol, our telemetry agent must collect and report topology data on each node in order to generate the combined topology). Multiple protocols can easily be supported on a single node and we are currently deploying nodes with both Babel and OLSR, so that we may slowly transition to a Babel-only mesh.