Routing and WiFi experimentation

The beginning of my work period was pretty busy, not always with Summer of Code things. My mentor math and I had already talked about a lot of the things that needed to happen in order to move qaul.net away from an OLSR based routing protocol and make it extendable as well.

As previously hinted, we are using Rust for the protocol implementation, allowing for easy integrating into the existing C code as well as giving us the option to bit-by-bit rewrite the entire software in Rust, a much more modern and forgiving language. The first thing I tackled was to design a common API for the qaul.net library (libqaul) to use to talk to any networking backend. The routing code holds the state of the network and allows the sending of direct and flooded messages into a network (regardless of implementation under the hood). But to do that we also had to define some common characteristics for nodes and messages.

In the end, a lot of the work was sitting down, going through old notes and determining what our protocol was supposed to do. We looked at existing protocols a lot, thinking about extendability and backwards compatibility. The protocol itself will be binary encoded, although not yet sure which format. There is msgpack, cpnproto/ protobuf as well as some Rust specifics (Rust Object Notation to mention one) to look at. But that shouldn’t actually matter for now. All the versioning and extend-ability are being done in the struct level of the protocol, meaning that we could even switch binary encoding half way through. Keeping the encoding and decoding written in Rust, this is actually incredibly easy with the `From` traits. But I digress…

The protocl we ended up designing can handle any type that already exists in qaul.net, as well as allows for custom user extentions – messages that have a type field and a random binary message payload which allows plugins on both sides to interact with it.

 

So…so far the routing core isn’t doing much routing. But that’s okay, that comes later 🙂 With the networking API in place, we actually have something what we’ve wanted for the last 2 years: a hardware abstraction over any networking backend. The API is implemented in Rust as a trait (think like a Java interface), which makes implementations and even implementation specific code very easy.

The next thing on our todo list is working out how WiFi direct behaves. This is kinda disconnected from the rest of the project, but it’s something that has to happen. For this purpose I’ve written a small demo app (still WIP at the time of this writing), which will let us explore the way that WiFi direct works, how to build mesh groups, etc. These experiments are still ongoing, and we hope to have something to show until the end of the week. I will probably publish a small article on my blog about it – check it out (if you’re reading this in the future 😉 )

All in all, the amount of code written in the first section of GSoC2018 is medium. We have however answered a lot of open questions, have a good plan on how to continue and hope to have more to show off by the time of the next evaluation.

If you’re curious about the progress being made, check out the github repository.

 

Until next time,
Katharina

Designing a userspace routing protocol for qaul.net

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.

  1. Actually designing a resilient, delay-tolerant routing protocol
  2. Building a networking abstraction layer which can handle multiple backends (Adhoc, WiFi-direct, ethernet, etc)
  3. 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.

Freifunk in Bielefeld

Seit Anfang 2011 gibt es auch in Bielefeld eine kleine Freifunk-Community. Nach einem initialen Vortrag auf der Netzwoche Bielefeld im Mai 2011 wurde mit der Entwicklung einer eigenen Firmware begonnen. Die bestehende Freifunk Software auf Basis von OLSR erschien uns als nicht mehr zeitgemäß. Deshalb versuchen wir unser Glück mit einer Konfiguration auf Basis von B.A.T.M.A.N Advanced.
 
Die erklärten Ziele unserer Konfiguration sind es eine komplett dezentrale und unkomplizierte Netzwerkkonfiguration bereitzustellenViele andere FF Firmwares verwenden eine statische IP Vergabe für die Nodes (WikiListen lassen Grüßen) oder
verwenden spezielle Nodes um IPs zu vergeben (z.B. Gateways). 
 
Für weitere Informationen besucht unsere Seite, besucht unseren Jabberchannel oder sendet uns eine Email.

Viele Grüße und bis bald,
Freifunk Bielefeld.

Hier noch ein Foto von unserem gut befestigtem Wunsch-Standort aus. 🙂
Sparrenburg Bielefeld

NinuxDay in Rome from November 27-29, 2009

The Ninux.org team announced the first “Ninux Day”, a weekend with about and for wireless communities. You will meet software and hardware hackers, geeks, nerds, engineers, artists, the curious and
academics. Experts from all over Europe offer technical and social presentations in the area of wireless community networks.

Join the Ninux Days in Rome, Italy, from November 27-29, 2009.

More Info here:

* http://wiki.ninux.org/NinuxDay2009
* http://wiki.ninux.org/NinuxDay2009en (English)
* http://wiki.ninux.org/NinuxDay2009it (Italian)
* Announcement: http://blog.ninux.org/2009/09/03/ninux-day-2009
* Ninux Blog http://blog.ninux.org

[via ZioPRoTo]