Implementing Pop-Routing - Midterm Updates


Hi Everyone!

Today has started the midterm evaluation, the deadline Is next Monday, so I have to show the work I have done ‘till now. It can be resumed in the following parts:

1) Refactoring of graph-parser and C Bindings

During the community bonding period I started working on the code of Quynh Nguyen’s M.Sc. Thesis. She wrote a C++ program capable of calculating the BC of every node of a topology [1]. I re-factored the code, and now it is a C/C++ shared Library [2]. I’ve also applied some OOP principles (Single responsibility and inheritance) and unit tests to make it more maintainable.

The interface of the library Is well defined and it can be re-used to implement another library to perform the same tasks (parsing the json and calculating the BC).

2)Prince Basic functionalities

After I completed the library a started working on the main part of the project. the daemon. We decided to call it Prince in memory of the Popstar.

This daemon connect to the routing protocol using the specific plugin (see below), calculate the BC using graph-parser, computes the timers and then it push them back using again the specific plugin. With this architecture it can be used with any routing protocol.I wrote the specific plugin for OONF and OLSRd. At the moment it has been tested with both, but I need to write a plugin for OLSRd to change the timers at runtime. For OONF I used the RemoteControl Plugin.

With these feature Prince is capable of pulling the topology, calculate the BC and Timers and push them back to the routing protocol daemon.


3) Additional Features: Configuration file, Dynamic plugins,

I wrote a very simple reader for a configuration file. Using the configuration file the user can specify: routing protocol host and port, routing protocol (olsr/oonf), heuristic, (un)weighted graphs.

As you can see from this Issue [3], I’m going to use INI instead of this home-made format.

As I said before I moved to a specific plugin all the protocol specific methods (pulling the topology and pushing the timers), to keep the daemon light I decided to load this plugin dynamically at runtime. So if you specify “olsr” in the configuration file just the OLSRd specific plugin will be loaded.



At the moment I consider this an “alpha” version of Prince. In the next 2 months I’ll be working on it to make it stable and well tested. The next steps will be:


  • Close all the Issues [4]
  • Write tests and documentation for Prince.
  • Write a plugin for OLSRd


Cheers, Gabriel






GSoC: The ECE configuration system - midterm update

the GSoC is nearing its midterm evaluation, so let's have a look at the current state of the "Experimental Configuration Environment" (working title)!

I started the project with defining models for configuration data, configuration diffs (that are used to modify data and store modifications) and schemas. All of the design documents I wrote can be found at:

I tried hard not to re-invent things that already exist in a more or less standardized way:

  • My configuration model is just JSON (without support for floating-point numbers right now, as the libubox blobmsg format ubus uses to represent JSON doesn't support them - I plan to fix this)
  • JSON Pointers ( are used to refer to elements of the configuration tree
  • The schema format uses a subset of JSON Schema (

Based on this design, I've started implementing the configuration management daemon eced. The page gives a good overview of the current features and usage of eced. Quite a lot is already working:

  • Multiple schemas can be loaded and merged
  • Default configuration is generated from the schemas
  • A ubus interface allows to query and modify the configuration
  • Config modifications can be loaded from and stored into a diff file

There's still a lot missing, so here's what I plan to do next:

  • Make something use ECE! UCI is well-integrated in OpenWrt/LEDE and can be used from C, Lua and shell scripts; all of these languages should also be supported by an ECE client library. An example schema to replace /etc/config/system does already exist and could be used to experiment with partially replacing UCI with ECE.
  • Support schema upgrades: When schemas are updated, this can partially invalidate config diffs. A way to deal with such inconsistencies must be defined.

Discussions and feedback have also led me to the decision to put a stronger focus to UCI interoperability. While I had only planned import and export of UCI configuration at first, I've realized that a two-way binding between UCI and ECE (i.e. an API-compatible libuci replacement/extension that will use ECE as backend) will be necessary for ECE to find acceptance. This will also allow to continue to use existing configuration tools like LuCI with UCI configuration converted to ECE.

I also plan to have OpenWrt/LEDE packages for ECE ready soon, so you can play around with the current implementation yourselves. Maybe I'll also set up a public host with ECE Laughing

Monitoring and quality assurance of open wifi networks out of client view (midterm evaluation)

Hey everyone,
Now we are on the midterm evaluation. I would like to tell you what I have done so far and what will come next. In the first post [0] I explained the work packages. In this post I will come back to the work packages  and show you what I have done for each package.
The first sub-project was the hoodselector. At the beginning of the work period I did some bugfixing for the hoodselector so that we where able to deploy the hoodselector in our live environment. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations. You can find a detailed discription here [0]. Retrospective I can say that the deploymend of the hoodsystem went without any major problems opposed to my first expectations. Currently we have 4 hoods active. Around Oldenburg(Oldb), Ibbenbüren, Osnabrück and Friesland. More hoods will follow in future. Open Issues can be find here [1].
The second sub-project was to create a propper workaround for building images with the continuous-integration (CI) system of Gitlab using make on multiple cores.
The Freifunk Nordwest firmware now has automatically built testing images that are not only build on a single core but can be built on multiple cores. And the architecture targets are also autogenerated out of the sourcecode. This makes it possible to generate images dynamically for all targets also including new targets that may come in the future. I implemented a small algorithm that manages the thread counter of make commands. I use the number of CPUs out of /proc/cpuinfo * 2 this means for each logic core will follow two threads. In example our server has 8 cores so the CI build process will automatically build with 16 Threads [2]. Here is an example of a passed buildprocess with our CI builder[3]. Actually it is not possible to build images with a high verbose output, because the CI logfiles will get to big. That makes it impossible to use the webfrontend for analyzing the buildprocesses. I opened an issues for this and discussed the problem with the gitlab developers [4].
The CI builder is very helpful for the developing process of the monitoring drone.
Following I would like to report about our first hacking seminar.
The first hacking seminar was on 28.05.2016. We started with two presentations. One about Wireless Geo Location and the second one about the Hoodselector. We recorded the presentation with our new recording equipment [7] bought using some of the money for the mentoring organisation and uploaded the recordings to youtube [5].
The first presentation was about geolocating with wireles technologies.
Based on the Nordwest Freifunk geolocator [6]

The second presentation was about the function of the Hoodselector

After this two presentations we had a smal disscussion about the presentation topics and than we started o
ur hacking session where the developers started coding on their projects.
Now all sub-Projects are finnisched and I will continue with the Monitoring Drone Project after I finish my Study exams. Also the date of next hacking seminar is set for 9th of Juli 2016. Again we will have two presentations. One on Gitlab CI and one about how to use our new Puppet Git repositories including the submodule feature. The presentations will be recorded and after the presentation we will have a coding session like last time.
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  <- Done
16. May 6:00 PM: GSoC Mumble  <- Done
Refine the roadmap  <- Done
23. May – 20. June: Work period 1 (4 weeks) <- Done
28. May 2:00 PM: hacker-session  <- Done
  1. Presentation about the hoodselector <- Done
  2. Presentation about the project[4] and the geolocator <- Done
13. June 6:00 PM: GSoC Mumble  <- Done
Tarek & Clemens exams!!!
20. June – 15. August: Work period 2 (8 weeks)
9. July 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble

DynaPoint update

Hi everyone,

here are some updates regarding DynaPoint. The idea was to create a daemon, which regularily checks the Internet connection and changes the used access point depending on the result. That way the handling with APs would become easier as you already could tell the status by the AP's SSID.

A daemon with basic functionality is already working. After installation, there is one configuration step necessary.
You have to choose in /etc/config/wireless which AP should be used, if Internet connectivity is available and which one if the connectivity is lost. You can do that by adding "dynapoint 1" or "dynapoint 0" to the respecive wifi-iface section.

You can also configure dynapoint via LuCI, although it's not yet complete.
I was struggeling a bit with it, because the documentation of LuCI is a bit minimalistic...
Here is a screenshot of how it currently looks like:

Next steps

To verify Internet connectivity, it is probably better to make a small http download than just ping an IP address.
Using "wget --spider" should be suitable for that.

Also, I will see if I can get rid of the required configuration step in /etc/config/wireless in the next weeks and provide fully automatic configuration.

If you want to test dynapoint for yourself, just go to

Overview: GSoC projects at

GSoC 2016 Introduction: external device handlers for netifd


It's time I started blogging about my Google Summer of Code project with Freifunk.

To begin, let me introduce myself. I am Arne, computer science student at TU Berlin and pursuing my Bachelor's degree. This is my first GSoC -- and the first time I contribute to an Open Source software project, so, naturally, I'm pretty excited to get to know the process.

My project aims at extending OpenWRT/LEDE's network interface daemon (netifd).

I've familiarize myself with the inner workings of netifd while I was working on a student project last semester. The result of that student project will assist me in realizing the GSoC project. Moreover, the existing source code will partially build the foundation of the new device handler which will be realized in this project.



Here's the general idea: Netifd allows the user -- as the name suggests -- to create and configure network devices and interfaces. Per device class, there is a hard-coded structure called a 'device handler'. Each device handler exposes an interface for operations such as creation or re-configuration of device instances of its class.

The point I'm tackling is the structures hard-codedness. Today, whenever someone wants to introduce a new device class, is necessary to alter the netifd code base and maintain these changes. The proposed mechanism allows to realize external device handlers as separate programs communicating via the bus system ubus. Accordingly, to introduce a new device class into netifd, one just needs to implement device handling logic and link it to netifd. Thus, no maintenance -- or knowledge of the innermost workings of netifd -- is necessary.

Building on my work from the aforementioned class I'll write a device handler to integrate Open vSwitch support into OpenWRT/LEDE using netifd. The 'ovsd' as it is called will relay calls to the device handler interface via the 'ovs-vsctl' command line utility to set up Open vSwitch bridges and ports.



I am hosting my code in a git repository that's included in the GitLab of the INET department which is employing me at TU Berlin. Once the code becomes usable, it will appear on GitHub here.

We also have a repository providing an OpenWRT/LEDE feed that bundles the Open vSwitch software with ovsd: (link will follow)


Testing is done on a PC Engines Alix 2 board which is part of our testbed:



As of today I have realized a mechanism to generate device handler stubs within netifd when the daemon is first started and before it parses /etc/config/network. The device class' parameters, such as its name in the ubus system and most importantly the format of its configuration, are stored in JSON files in /lib/netifd/ubusdev-config/. The logic to parse a configuration format from JSON files existed already within netifd but was only used for protocol handlers before. I adapted it to generate device handlers dynamically.

When such a device handler is generated, it subscribes to its corresponding external device handler using ubus. This way, the latter can generate events asynchronously for the former to react to.

In order for this to work, the external device handler must be up and running before netifd attempts the subscription.

I also realized a simple proof-of-concept implementation that works in one simple case: create an ovs-bridge with one or more interfaces like this example /etc/config/network file demonstrates:


config interface 'lan'

    option ifname 'eth0'

    option type 'ovs'

    option proto 'static'

    option ipaddr ''

    option gateway ''

    option netmask ''

This will create an Open vSwitch bridge called 'ovs-lan' with the port 'eth0' -- and that's about all it does right now. Error handling is missing and more complex options like setting OpenFlow controllers or adding wireless interfaces don't work yet.



Among the first things I'll tackle when GSoC's coding phase begins are adding the possibilities to incorporate WiFi-interfaces to the bridges created with external device handlers and introducing the missing parts of the device handler interface. Since I'm dealing with netifd and the external device handler which is an independent process running asynchronously, getting their state to stay in sync will take some work. I need to think about the way the callback system that comes with ubus' pubsub-mechanism will function. In the end, it is supposed to be abstract enough to work not only for my Open vSwitch use case but for any external device handler.

Then, further into the coding phase, I want to increase feature coverage of the Open vSwitch options, so that users can assign OpenFlow controllers for their bridges like so:


config interface 'lan'

    option ifname 'eth0'

    option type 'ovs'

    option proto 'static'

    option ipaddr ''

    option gateway ''

    option netmask ''

    option of-controller ''

In the end I would like to have the mechanism implemented and documented so that others can build on it. Documenting my work is especially important to me, because I found myself frustrated with the scarcity of the netifd documentation more than once before. I wish for my code to become a part of OpenWRT/LEDE and be extended and improved in the future and I would like to make it easy for anyone insterested to doing that with a helpful manual and commented code.

I'm excited to get started and hope to find the time to blog about my progress here, regularly.

Monitoring and quality assurance of open wifi networks out of client view

Hey everyone,
My name is Jan-Tarek Butt and I am in my second term of computer science at Emden University in Lower Saxony (Germany). I am one of the students that are participating for Freifunk in the Google Summer of Code 2016. In the following post I would like to introduce you to my Google Summer of Code project. I split up the project into 3 main subjects: Mainline project, sub-projects and seminars.
Before I explain the three mentioned subjects I would like to give you some background information about the project in general. My project mentor is Clemens John. He studies computer science at University Osnabrück in Lower Saxony (Germany) and recently started to write his bachelor thesis. As part of his bachelor thesis he will build a monitoring and administration software for open wireless networks called "Netmon-SC" based on a previosly existing software that will be rewritten to follow a decentralised idea. The coarse structure of Netmon-SC will consist of a core module as a data storage backend that can be queried by using a REST API based on NetJSON. In addition to the REST API the core module will include a plug-In system which developers can use to easily extend the core module to build data storages for creating visualisation tools, quality assurance metrics or any other community specific tools like special administration applications.
My mainline GSoC project is to develop a new firmware for routers based on openWRT or LEDE. This firmware will  be the basis for an application to monitor the clients view onto an open wireless network. From now on we will call this firmware the "Monitoring-Drone". This monitoring firmware will gather quality assurance metrics and send them to Netmon-SC. This metrics will help developers and administrators to enhance the quality of open wireless networks and find bugs more easier. The firmware will include an API package to communicate with Netmon-SC. It will also contain a small LUCI web-interface for basic configuration e.g. wireless network settings etc. Additionally to the basic settings it should be possible to integrate small plugins in form of  .sh or .lua files witch contain custom commands.This will allow communities to gather network specifics metrics without compiling community specific firmware images. The API for communication with Netmon-SC, the web-interface and the plugin system will embedded into a package bases structure. The git repository for this project can be found here.
Now to the sub-projects. Sub-projects are small projects adjacent to the mainline project. The first sub-project is the so called hoodselector that I finished reviewing on Mai 21th. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations based on geostationary fixed quadrants for batman-adv mesh networks. It detects in which quadrant the node is in by using wireless location services and configurates the router using the settings that have been stored for this quadrant. In conclusion the hoodselector enables us to build scaled decentralised mesh-networks. It is a small program on open wireless routers on the Nordwest-Freifunk community network.
The second sub-project is, to create a proper workaround for building images on a multicore system instead of a single core system by using Gitlabs continuous-integration (CI) feature. This will fully automate the firmware image building process for the Monitoring-Drone and also for the open wireless firmware images from the local community.
The third sub-project are regular seminars. The idea of this seminars is to give earned knowledge to the public and also acquire new developers for open wireless projects. The seminars should have one or two short presentations about technical processes from open wireless networks, for instance how the hoodselector works or how batman-adv works. The Presentations will be video recorded and uploaded to the internet. After thous presentations on the seminars I plan short discussions about the contend of the presentations. Afterwards hack-sessions should do force forward the developing processes for the Google Summer of Code project and illuminate the opensource software development scene of the open wireless project.
Last but not least we created a project timeline. Clemens and I, will have regular Mumble meetings during the GSoC, at the middle of every month. On this meetings we will discuss the work already done and what should happen next. Beside the work on the main project we will also use the meetings to plan the next seminar that will always follow at the end of each month.
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  ← Done
16. May 6:00 PM: GSoC Mumble ← Done
Refine the roadmap ← Done
23. May – 20. June: Work period 1 (4 weeks)
28. May 2:00 PM: hacker-session
  1. Presentation about the hoodselector
  2. Presentation about the project and the geolocator
20. June – 15. August: Work period 2 (8 weeks)
Tarek & Clemens exams!!!
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. actual unknown
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble

Jan-Tarek Butt

Sharable Plugin System for

Hi everyone,

I'm Anu Vazhayil, exchange student at University of Paderborn from India. I am one of the Google Summer of Code participant for the project is a mesh network communication app which can be run in Linux, OSX, Windows and Android. It can be used to send text messages, file sharing and even make voice calls with people who are connected to this network without being connected to internet or cellular networks. There is also a feature to share your internet with the other users connected to the network. All this makes it a cool app which everyone will feel to try atleast onceWink If you have not installed it in your system, you can still connect to the network via web interface after connecting to a wifi.

As part of the GSoC project, we are planning to extend the usability of the messaging system of The messaging system can be used as a communication layer for other purposes like location sharing, sending contacts etc. Such apps/extensions can be downloaded by the user as a zipped file which will automatically get downloaded to the web plugin directory available to the web server. It also proposes an additional feature to share the installed plugins with other users in the network over file sharing.

The following needs to be implemented for the project:

  • Plugin API: to describe the features of a library and how to interact with it. It defines a mechanism to use the messaging system for plugins and give it access to the topology.
  • Plugin structure: a zipped folder with a special extension that can be shared with other users in the network over file sharing.
  • Plugin management function: Installation and plugin sharing. Once the Plugin is installed, it is copied and extracted to a directory in the web server.
  • Sample Plugin: Share the location details of the user. It will have access to the user's location through the API implemented.
Mockup UI
Stay tuned for my next blog posts with the updates regarding my projectLaughing. I will also update my blog: in the coming days. Our coding period starts today so, I wish All the best to other GSoC students too. Happy coding everyone!
Syndicate content