Hi – my name is Katharina, I’m 24 years old and a computer science student at the HU-Berlin. I’ve done the GSoC2016 before for qaul.net and have been an active contributer for the past 2 years. This year I want to tackle something we’ve been postponing for a while…
qaul.net is a communication app that’s based on Freifunk technologies (namely OLSR) which enables people with no access to the internet to communicate with each other easily, using the devices they already own (phones, tablets, laptops, etc) and without needing to be experts in networking technologies.
Unfortunately qaul.net has an issue, namely OLSR. The routing backend is based on manipulating kernel tables and as such needs to run in root-mode. Which isn’t possible on many devices (such as phones and tablets). Furthermore it makes heavy use of the WiFi adhoc mode which isn’t present anymore in modern phones and tablets, putting in another reason for users having to root their devices.
We want to change this to make installation easier (a simple .apk file could be dropped onto a normal phone) and support newer devices without having to install any kernel-level modules. So that’s the why. What about the how?
Well, that one is a little tricky to be honest. Large parts of the qaul.net core library are based on the fact that routing is handled externally and some parts of the code are even olsr-specific. There are three main parts to this challenge.
- Actually designing a resilient, delay-tolerant routing protocol
- Building a networking abstraction layer which can handle multiple backends (Adhoc, WiFi-direct, ethernet, etc)
- Integrating the new routing core into the rest of the library.
When it comes to designing the protocol we want to let BATMAN inspire us greatly. Each qaul.net node doesn’t need to know the entire topology of the network, only where to roughly send packages for them to be delivered. This also means we can build a delay tolerant system. This module (which I’ve called routing core for now) will be written in Rust, a low-level programming language which can integrate into the rest of the C source code easily, without being as low-level and feature-sparse as C itself. Developing it as a separate module with an API also means that we can take it out of the context of qaul.net and do experiments with it in different settings.
Building a networking abstraction API will require knowledge of different backends. For this we will do experiments with WiFi direct on Android (and maybe iOS if we find hardware) to see how it behaves, how we can build meshes with it, etc. There are a lot of open questions for this which will need to be answered but hopefully at the end of GSoC2018 we’ll have some answers and code to go along with it.
I’m excited to get working on this. It has been about two years in planning and with it we can make qaul.net more accessible to more people.