HELLO WORLD
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.
THE 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.
MY DEVELOPMENT ENVIRONMENT
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:
WHERE I AM AT
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 ‘172.17.1.123’
option gateway ‘172.17.1.1’
option netmask ‘255.255.255.0’
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.
THE ROAD AHEAD
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 ‘172.17.1.123’
option gateway ‘172.17.1.1’
option netmask ‘255.255.255.0’
option of-controller ‘1.2.3.4:5678’
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.
). But that should give you an idea of what is to come in the UI department.
