In 2016 we found 9 students doing Google Summer of Code projects for freifunk. This is an overview on all our projects including links to repositories and further information:
|A schema-based configuration system for OpenWrt||Neoraider||https://gitlab.com/neoraider/ece|
|DynaPoint - A dynamic access point validator and creator for OpenWrt||Asco||https://github.com/thuehn/dynapoint|
|Monitoring and quality assurance of open wifi networks: the client view||Tarek||https://git.nordwest.freifunk.net/ffnw-firmware/monitoring-drone|
|netifd extension: external device handlers||arkap|
|OpenWrt - poWquty (poWer quality)||Neez||https://github.com/neez34/|
|Provide a cryptographic implementation for Qaul.net||spacecookie||https://github.com/spacekookie/qaul.net||https://spacekookie.de/gsoc2016/|
|Sharable Plugin System for qaul.net – Mesh Network Communication App||Anu||https://github.com/anuvazhayil/qaul.net||https://github.com/anuvazhayil|
|SWOON: Simultaneous Wireless Organic Optimization within Nodewatcher||marn|
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.
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 '188.8.131.52: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.
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 qaul.net.
Qaul.net 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 qaul.net network. All this makes it a cool app which everyone will feel to try atleast once. 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 qaul.net. 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:
I am Gabriele from the Ninux community. I am participating in GSoC 2016 for the first time and I am very glad I have been accepted as a Student for Freifunk. I am from Florence, Italy. Here I’m studying Computer Science, soon I will graduate and I hope to use the results of this project to write my bachelor thesis.
Four years ago, with others community networks’ enthusiasts we have funded Ninux Firenze, the fist Wireless Community Network in Florence where I had the chance to learn how these networks work and to meet many others people interested in this field. The network is constantly growing, and now it counts almost 20 nodes. In May ’14 I have been for the first time to Wireless Battle of the Mesh in Leipzig where I met the Freifunk community. For this GSoC I will work on a project called PopRouting:
OONF (OLSRv2) is a link state routing protocol. It works sending periodical messages to his neighbors with the aim of transmitting information about topology changes. With these information each node of the network is able to calculate the paths to reach any other destination. These messages are periodically generated, based on the configuration parameter that regulates the sending interval. A short period will make the network react rapidly but it will also cause a large overhead due to control messages. Pop Routing is a recent technique that takes advantage of the knowledge of the network topology to find the optimal value for the OONF’s timers. Using Pop Routing every node computes the “betweenness centrality” of every other node and uses it to calculate the optimal trade-off between convergence and overhead for its timers. The algorithm has been developed at the UniTN and the algorithm to compute the BC in C++ is available as free software. My goal is to code a daemon (in C) that is able to calculate autonomously the BC of the network and push it to OONF using the telnet plugin.
In this month of community bonding I have been to Wireless Battle of the Mesh v9 in Oporto(PT). There I met the OONF developers and we discussed how to implement this inside OONF. I also gave a presentation on the project. After the Battlemesh I started working on the algorithm developed by UniTN and I made a C/C++ library out of it .
Today I will start coding for the GSoC, stay tuned and I will give you more updates soon.
Please allow me to introduce the poWquty Project within Google Summer of Code 2016 at Freifunk.
The big picture behind this project relates to the energy production and consumption. Sustainable energy production and consumption are crucial for a prospering life on earth. The importance of energy led many theorists to even define the level of civilization by its energy profile. With the renewable energies shift the energy production paradigm from centralized to decentralized energy production which poses one of the next big challenges, which will influence the energy production in the future years.
From the big picture we move to the concrete case, increasingly faced when dealing with renewable energies: monitoring and control.
The emerging smart grids include an inherent need for communication for monitoring and control purposes in a more and more dynamic environment. One of the major challenges is monitoring the power quality parameters in a decentralized manner. In such case, decentralized information need to be retrieved and transported with the lowest latency possible. One way to solve this challenge could be to install expensive infrastructure to each point. The better way is to use wireless mesh infrastructure that could also serve this purpose.
Here where Freifunk comes in: The Freifunk mesh network is an outstanding example for a decentralized infrastructure that could be augmented with grid related functionalities to cope with future energy challenges. In order to use wireless mesh networks such as Freifunk for energy monitoring, we could use extra hardware that does the power measurements and use the wireless networks solely for transporting the information. The drawback of this is the need to install separate hardware. But, since all routers run on power, we could integrate the measurements into the router, which is the main goal of this project: to enable power quality measurements on OpenWrt.
Here is the initial plan how to do this. First we need to retrieve voltage samples from the power grid. For the beginning we will rely on an oscilloscope device that delivers the real time samples over a USB interface. This way voltage samples from the electric socket are retrieved at the router. With these voltage samples we can go ahead and calculate the power quality parameters, using moving window algorithms, fourrier transform, and z-transform to get the phase angle, the effective power, the frequency, and the harmonics. This calculation should be time, and memory efficient since it has to run on the OpenWrt embedded devices. Once these values are calculated we need to think about how we want to make them available for retrieval over IP networks.
Now we come to the Code: The goal of the project is to create an OpenWrt package which ensures three functionalities:
1- Retrieving sample data from the measurement device
2- Calculating power quality parameters form the retrieved samples
3- Provisioning of the calculated parameters for retrieval
This project is intended to strengthen the role of open software in the uprising smart grids by providing some essential functionalities, communication devices need to have in the context of smart grids, especially in regard to the future role of the home routers in the future energy solutions.
More updates on this will follow in the next weeks.
I'm Matthias (aka NeoRaider), and this year, I'll participate in the Google Summer of Code for the Freifunk project.
The goal of my project is to develop an alternative to the UCI configuration system, as UCI has a number of issues that make it cumbersome to use in some situations.
One of the basic issues of UCI that affects many Freifunk (or generally community mesh) firmwares is the upgrade behaviour. Mesh firmwares usually contain elaborate default configurations, which set up network interfaces and other things to allow participating in a mesh without deep knowledge of the setup.
But this setup needs to change from time to time, as the firmware is upgraded. In the Gluon firmware framework, we usually solve this by providing upgrade scripts which modify the configuration after flashing the firmware. Writing these script is often a tedious task, and the scripts easily break when the configuration differs too much from the expected one.
But the ability to change the configuration is important for many Freifunk users: They want to change the role of ethernet ports, WLAN settings, and a lot more. But UCI doesn't provide information how a setting was changed: if a script encounters an unexpected value, it can't find out if it is an old default value, or was changed by the user. This often leads to a difficult choice for the script author: either to overwrite the value unconditionally, maybe disregarding voluntary configuration changes, or not to overwrite it, rendering communities unable to change certain configuration during upgrades.
My project aims at solving this by saving the user configuration independently of the defaults provided by packages. This way, a package upgrade can change the default values, but explicit user configuration will not be affected.
Another issue is that the upgrade scripts are usually part of the packages that bring the configuration. Removing a package will leave the configuration behind, which is usually a good thing (for users which know about this and may be interested in the the old config), but for mostly-automatic upgrades, old configuration may accumulate, which can quickly become problematic on devices with very limited flash.
I plan to fix this by basing the new configuration system on schema definitions, which specify which configuration options and values are valid. The schema will probably be based on JSON, as there are already lots of existing systems for defining JSON schemas, which may be used for my project or at least serve as inspiration. This will also finally provide real datatypes for the configuration and make things more consistent (finally no more 1/true/on/yes/0/false/off/no booleans!). If we want too keep the package/section/option organization of UCI, or rather allow defining schemas for any JSON structure, is still a subject of debate.
Instead of going into detail even more in this post, I'll provide a link to my Gitlab project: https://gitlab.com/neoraider/ece
Design documents, examples for configuration and schemas, and first code will start to appear there very soon
I am Tobias, a Computer Science student at the TU-Berlin. I am glad to have the opportunity to participate at GSoC for Freifunk this year.
My project aims at making the handling with access points in OpenWrt/LEDE easier. The goal is defined as follows: Find an easily configurable solution (with reasonable defaults) for making the wireless access SSID in OpenWrt/LEDE dependent on a set of network conditions.
What does that mean? Consider the following example. You have a wireless access point with SSID "Freifunk". Suddenly for whatever reason the AP looses Internet connectivity without anyone noticing it. When users now connect to this AP, expecting a working Internet connection, they get frustrated, because they can't check their emails or surf the Internet.
With DynaPoint I want to develop a daemon, which regularly monitors the Internet connectivity. When it's lost, the SSID will automatically be changed. In this example it could be changed to "Freifunk-offline". When Internet connectivity is re-established, the SSID would automatically be changed back to "Freifunk".
This way users as well as admins get informed about the state of an access point just by looking at the SSID.
To verify Internet connectivity the first obvious step would be to do a ping. For this purpose there already exists a package called pingcheck, which I am planning to use. Further steps could include DNS-Queries and HTTP-Downloads.
Speaking about easy configuration and reasonable defaults, I want to require as little configuration steps as possible, but also provide enough configuration options to be adjustable to different kind of setups. Ideally the configuration will also be possible via the LuCI web interface.
Until next time,