This is the final blogpost for my GSoC project for the Freifunk-API Query Client.
We want a comfortable tool to query all the Freifunk API files as there are nearly 100 communities all over Germany providing their data. There are already several applications like our community map, a common calendar, our feed aggrator or the community podcast collector. But it's still hard to find communities by properties like routing protocols or focus topics.
When we began this project we only planned to query the generated JSON data for the community in a browser and additionally provide query results via a webservice. But then we talked to several people and we heard about DeepaMehta with features like connectors to OpenStreetmap. So we did something what you don't do normally: We changed our project goals before the midterm evaluations.
DeepaMehta is not just another database product, it provides a different way to store and handle data. It uses a graph to store connections between items and allows to modex complex datatypes and associations between them. We had to change our mind and had to learn a new kind of thinking. The API data is constantly evolving and changing and there a lot of cross-references in the data e.g. links to various nodemaps. We think the switch to DeepaMehta is useful because we can query the graph and add new relations and data without problems.
It's difficult to handle different spec versions if you want to query all API files, because some fields changed, other fields were added to the specs or got another meaning. In an ideal world all communities update their files as soon as possible. But we all know, it will never happen like that. As a workaround we first focused on less fields, available in all versions.
What we got
We're able to import communities from the API directory as a base entity. We also tried some different ways to import and store the specs, but we need some improvements here. By using the summarized API file, the import of our payload can be done via the DeepaMehta REST API.
The switch to DeepaMehta brought a lot of complexity to the project and I'm personally not happy my results at this point because I had trouble to spend enough time for the project. Additionally some basic problems like dealing with changing schema and data import are not really solved well at this point. The data is in DeepaMehta and can be queries with the included client but it's not in a state where it's usable for the community.
Overall the GSoC was an interesting experience for me. Through I've failed to set aside enough time for the tasks. The timely overlap with university lectures does not make it easier. So I can only recommend to know beforehand that you'll have enough time to accomplish your goals. But the support from the Freifunk community was always great and helpful! As the project is not a state that can be considered 'ready' I'm continuing working on it.
I definitly want to finish the work at least to point where it can be used by the wider Freifunk community.
The default DeepaMehta client isn't designated to query a lot of fields like our API provides. Here we need a new web based client to provide users an interface to select fields and get a proper response.
Work will continue on integrating the API data and DeepaMehta.
Hi everybody, this is going to be my last blog post as a participant of GSOC2014. I'm very sad about this, those have been very hard worked months but very formative.
I improved both my coding skills but above all I have earned a work methodology thanks to my mentor Federico, who said to me to be more reflexive and to be more precise in what I do.
I have learnt some aspect of versioning (Git) I ignored before and learned much more on Python than I did by myself.
This is the “change log” of the last time period of the program: we developed a new backend, the HTTP backend. It aims to retrieve informations from the web admin interface of AirOS devices, that's why we called it HTTP.
We wrote documentation about all the project, describing all the things an user should do both to contribute or use Netengine, trying to be as much more clear and to make it simpler as we could.
Unfortunately this is my last year as a student, no PhD on my way (for now), so I will not be eligible at all for next editions coming.
Greetings and thanks: I would like to thank Ninux , the community network I’ve worked with. I’ve had the possibility of joining their meetings, to talk a lot with every member and to be supported every time I had some problem about what I was doing.
Obviously my mentor Federico Capoano, Mario Behling from Freifunk who supervised projects.
Thanks to this year's GSoC, a lot of work has been done on nodewatcher v3 platform. It now has a better, modular monitoring agent that can run on OpenWrt-supported devices, with a new JSON-based output format that can be easily reused by other projects as well. The platform has been ported to the latest stable version of Django (1.6) together with all migrations and dependencies. Development environment setup now uses Docker and fig in order to make it very easy to dive into the code without having to battle with various dependencies.
The API for access to node configuration and monitoring data (registry API) has been much improved, with better, more usable querying capabilities and performance. During development we have discovered a bug with cascade deletions and polymorphic models in Django. Node configuration editor based on the registry API now supports references between form models that have not yet been saved -- this functionality enables configuration of bridge interfaces which are now also supported by the firmware generator. I have implemented type support in the datastream library for long-term monitoring data storage with a new type for storing graphs as datapoints. This enables nodewatcher v3 to use datastream to store how the network topology evolves over time.
All the code is available on GitHub in several repositories:
Here I present you a report of the finals state of my GSoC project. For further information feel free to contact me using the channels described in the github and documentation.
“BGP/Bird integration with OpenWRT and QMP”  project's main goals were to improve Bird4/6 Daemon  adding a better integration with OpenWRT bringing UCI configuration to it, to add an user-friendly interface to make it easier using the LuCI web-framework, to be able to port it to QMP mesh networks and, finally, to automate the route exchange and metric translation between Guifi.net (BGP) and QMP (BMX6) .
Current solution consists on two OpenWRT packets: bird4/6-uci and bird4/6-luci. While bird4/6-uci allows the user to modify Bird’s configuration and apply it using the init.d script, the bird4/6-luci package brings a web interface to make this UCI configuration even easier.
Regarding bird4/6-uci package, UCI configuration scheme was agreed with Bird main developers owing, not just to make a solution, but also to consensus its development and characteristics with their main developers. The package includes a DOCUMENTATION file with all the available options, its description and examples.
Regarding bird4/6-luci package, it brings all the necessary files to add LuCI web-based configuration interface and has bird4/6-uci as a dependency.
Finally, the solution used to automate the translation and exchange of routes between BGP and BMX6, uses Bird filters instead of an external developed tool:
First of all, as BGP routes are automatically exported and imported only using UCI configuration, the efforts were put into the reverse part. Second, initial experiments were done in the WiBed platform , owing to be able to repeat and test the solution without the possibility of “breaking anything”. Once the solution was stable enough, packages were installed in a QMP mesh with 5 nodes (2x WDR4300, 1x WDR3900, 1x WRTNode and 1x WR703N) and also connected with a Mikrotik RouterBoard 750G to check the routes exported. Moreover, some tests were made connecting the RouterBoard to Guifi.net’s UPC point, working with more than 500 routes.
Example of original Bird configuration:
log "/tmp/bird4.log" all;
debug protocols all;
router id 10.1.26.50;
Example of the same configuration using UCI:
config global 'global'
option log_file '/tmp/bird4.log'
option log 'all'
option debug 'all'
option router_id '10.1.26.50'
option name 'aux'
An example of the LuCI configuration web page can be seen here:
Example of BMX6 Routes and how are they filtered:
# ip r show
10.0.0.0/8 dev bmxOut_HW-Ermi proto static metric 1024
10.1.32.0/27 dev bmxOut_HW-Ermi proto static metric 1024
The pattern used in IPv4 filters is the device name "bmx*" and also the metric "1024" owing not to repeat or export internal routes.
In IPv6 the procedure used is to filter the 60 kernel table, as it contains all BMX6 iroutes:
# ip -6 r s table 60
fd66:66:66:8:de9f:dbff:fe35:17b6 via fe80::de9f:dbff:fe34:17b6 dev wlan0.12 proto static metric 1024
fd66:66:66:a:de9f:dbff:fe34:17b6 via fe80::de9f:dbff:fe34:17b6 dev wlan0.12 proto static metric 1024
Both package repositories are actually in my personal Github account  and .
Finally, I want to thank Freifunk for the opportunity given to me with this GSoC project, to my mentors Roger Baig and Axel Neumann, to Pau Escrich for his support during the project and to Guifi.net and QMP project and their communities for the support received.
Eloi Carbó Solé.
Wie jedes Jahr, trifft sich auch dieses Jahr die hallesche Freifunk-Community im Sommer am Hufeisensee. Es ist ein regionales Treffen, welches offen für alle Freifunk-Communitys ist. Hiermit möchten wir euch einladen am 19.07.2014 vorbei zu schauen.
Diesmal sind wir zu Gast auf dem Vereinsgelände vom Tauchclub Orca in der Schkeuditzer Str. 70 | 06116 Halle, wo wir uns ab 15 Uhr treffen. Das Gelände bietet alles, was Freifunker für ein produktives Treffen benötigen: Freifunk, Internet, Strom und Grill sind genauso vorhanden, wie Tische und Stühle um eigene Rechentechnik aufzubauen. Die Freifunk Community aus Halle will dieses Treffen nutzen, um einen eigenen Förderverein zu gründen. Der Förderverein soll die Aufgabe übernehmen, das Projekt Freifunk in Halle organisatorisch zu unterstützen. Weitere Informationen gibt es im Freifunk.net-Wiki. Fragen und Anregungen können auch bei uns im Forum diskutiert werden. Gäste werden gebeten, sich anzumelden, um besser planen zu können.
Unsere kleine Community in Bielefeld wächst zur Zeit ruhig aber stetig. Jetzt wurde unsere Webseite komplett erneuert und unsere Mailingliste ist auch endlich von googlegroups umgezogen, nachdem immer mehr Leute gemeldet haben das ihr Emails nicht ankommen würden - wer da böses denkt. ;-)
Auch ist eine neue Firmware verfügbar (0.3), die nicht nur stabiler läuft sondern auch viele neue Router unterstützt. An dieser Stelle einen Dank an das Gluon-Projekt für einige Pakete und Patches die wir übernehmen konnten (autoupdater / traffic control). Für einige Modelle mussten wir aber aber auf eine noch experimentelle OpenWrt Version zurückgreifen (Barrier Breaker). Aber es funkt! :D
Heute gab es auch einen Vortrag zum Thema Freifunk im Rahmen der Netzwoche in der Universität Bielefeld. Vielleicht wurde die eine oder andere Person dazu inspiriert einen Router aufzustellen oder aktiv mitzumachen. Die Folien sollen bald veröffentlich werden, so dass auch andere sie nutzen können.
Photo taken from https://twitter.com/christianheise/status/472746947569520641
From the 29th May to the 1st of June we were with Andi and Bernd from Weimarnetz at the wunderful c-base Raumstation. We visited the Wireless Community Weekend. It was my first experience of this kind of community event and I enjoyed it very much.
Beer and Bratwurst did harmonize quite well with technical talks about OpenWrt and the Freifunk Community. I was especially surprised how diverse and open the community is and how enthusiastic everyone involved was.
Andi and Monic talked about the progress on the Freifunk API and presented their work. At the end of their talk I had the chance to present my work on the query client for the API. Here are the slides.
Shortly after the talk Jürgen Neumann from Freifunk Berlin came to me and introduced me to DeepaMehta. My original plan was to use something like NodeJS for the backend the storage of the API data but DeepaMehta looked promising and offers unique features I didn't even thought off.
So after talking with Andi about it we decided to use DeepaMehta as the foundation and storage tool for the API data. A seperate blogpost for the GSoC midterm evaluation will outline my work in this direction.
Overall it was a very exciting weekend for me at #ffwcw 2014.
A quick update on what is happening regarding my GSoC project with bringing nodewatcher v3 platform closer to reality. Version 2 of nodewatcher used its own simple key-value format and a bunch of shell scripts to provide monitoring data. In order to bring this into the modern era where JSON and ubus are available as compact libraries on OpenWrt by default, I have in the last few days created a new modular OpenWrt monitoring agent that can run on nodes and periodically obtain data from various sources (directly from procfs, from uci, from netifd via ubus, from nl80211 netlink API via OpenWrt's libiwinfo, etc.).
The daemon is implemented in C and different data sources are implemented as loadable shared object modules, enabling simple extensibility. Nodewatcher agent then provides all of the collected data in two ways: a) it can directly output data to a JSON file that can be served via HTTP; and b) it also provides an ubus object called nodewatcher.agent that exposes a get_data method, so other applications can obtain the same structured data as an ubus blobmsg. The nodewatcher monitoring agent could perhaps also be reused by the proposed Freifunk Monitoring and Administration Panel.
The nodewatcher-agent repository is hosted on GitHub with a README file providing a quick description of the used format, the ubus API and the currently implemented modules:
I have also packaged the agent for OpenWrt so it can be installed together with its various data source modules via opkg. The packages are available in the nodewatcher firmware package repository:
The agent and its packages should be considered alpha and the schema is still subject to change.