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.

VRConfig – Visual Router Configuration for OpenWrt

Hi,

I am Tobias, a Computer Science student at the TU-Berlin. This is my second time participating in GSoC for Freifunk.
I am excited about this project as it helps to reduce the entry barrier for inexperienced users of OpenWrt and its web interface LuCI.

When you look at the current LuCI Webinterface you will notice that it looks fairly decent, especially with the Material Theme.
However for an inexperienced user without a technical background it surely looks scary. All the text full of technical terms with few pictures can look like a book with seven seals.

This project aims to introduce a graphical configuration mode.
To make the configuration interface more connected to the actual router the user owns, we want to display an image of the backside of the ports in the web interface.
The user shall be able to interact with this graphical representation of the router by hovering and clicking on the different parts like LAN ports, antenna etc.

What are the necessary steps to archive this goal?

First, we need pictures of the backside of all the different router models. Her the idea is to collect them via crowdsourcing by the community. Everyone can take a picture of their router and upload it to a Git repository. Also, the location of of the router components must be marked on every picture. For that I will develop a small application which allows the user to annotate a router picture and generates a metadata file.
Second, the annotated pictures need to be integrated into the OpenWrt buildsystem.
Third, a LuCI application needs to be developed to display the result as an interactive graphic in the web interface.

In the next blog post I will go into more detail on the individual steps as well as update you about the progress.

GSoC 2018 – Better map for nodewatcher

Hello everyone,

My name is Marin and this year through Google Summer of Code I am contributing to the nodewatcher project and with these blog posts I will keep you updated on my progress.

Nodewatcher is one of the projects of wlan slovenija open wireless network. Its main goal is the development of an open source, modular community-oriented platform used for network planning, node deployment, node monitoring and maintenance. Currently it is used to monitor more than 1600 nodes in multiple countries. I got acquainted with nodewatcher when I joined a Croatian organization called Otvorena Mreža who uses nodewatcher to monitor their nodes.

While working with nodewatcher on Otvorena Mreža there was a recurring problem of not noticing offline nodes on time, we had an alert system that would constantly get flooded if a node kept restarting and that would hide the fact that another one is offline. Nodewatcher is based around monitoring and control of nodes so the best way to monitor multiple nodes at once should be the map, because you get a fast overview of all of them and you can also focus on one of them. The current map while functional, it only shows currently active nodes and it could do so much more. With my project I intend to add features that would allow easier and more detailed overview of nodes.

Some of the features that have came up as necessary are:

  • ability to get a fullscreen map to make it more presentable and easier to inspect
  • when hovering over a node it should list a short description about it i.e. name and number of users
  • toggle buttons to enable and disable which nodes to show (online, offline, idle)
  • color representation of the current status of the node, most importantly it should be easy to spot nodes that have gone offline recently

These are just some of the functionalities that need to be implemented to the map, after that I hope to get feedback from other nodewatcher users to see if anything else should be added or changed. Currently, the next step is to analyse the current code and see if it should be completely redone or is it possible just to upgrade it.

Ground Routing GUI in LiMe App

Introduction of the project

There are many cases in which equipment attached to libremesh routers is used to make point-to-point links. This is known as ground routing. There is a way to configure routers to work through these links in a completely normal way, without splitting the experience of the mesh. Currently, it requires intervention by using uci commands or by typing the file configuration file directly. The idea is to build a simple configuration screen for LiMe app, which allows users to make use of this feature without major complications.

About me

My name is Marcos Gutierrez, I’m from Argentina and I’ve been working with the Libremesh team for two years. I am a user and member of QuintanaLibre, a mesh network where LibreMesh is used.

Project requirements

  • Build a ubus module that writes and tests the ground routing settings in lime.
  • Build a user interface within the LiMe app to configure settings and display alert messages if necessary.
  • Deploy a use case and validate that it works in the real world.
  • Bonus: If there is time left to generate a LuCi view with the same capabilities.

GSoC 2018 – Easily Expandable WIDS – Introduction

Hello,

I am Alex and I want to create a framework for making an easily expandable wireless intrusion detection system this summer. The objective is to create a working environment which can be expanded with microservices to detect attacks on Wi-Fi networks and which fits easily within rather large organizations instead of small private setups.

All the things are happening on GitHub and thus this introduction is based on the README I created having this blog post in mind.

Background

Existing WIDS Tools

Analyzing 0x90/wifi-arsenal especially in search of wireless intrusion detection systems (WIDS) I realized that there just is no complete ready-to-go solution yet, at least regarding free and open source software (FOSS). For me a WIDS should serve the following needs:

  • detection of most of the known Wi-Fi attacks
  • scalability and thus being able to work within big organizations
  • simple expandability (there are always more attacks to come ;-))

Although there is indeed software on GitHub which can be used to detect Wi-Fi attacks, they are usually specialized on some attacks and/or they are hobby projects which would not fit in setups of bigger environments. Please have a look at the defence-related Wi-Fi tools on the wifi-arsenal list.

An exception should be mentioned: Kismet. It is probably the most famous and complete FOSS Wi-Fi solution and very popular. Still, it does not seem to fulfill the above necessities completely. And it is probably not the objective of Kismet to be a full-featured WIDS either. Instead it has many features for pentesting Wi-Fi networks and other interesting stuff.

Why Not Just Expanding Existing Programs?

One solution would be to simply add needed functionality to Kismet. And this is definitely a good idea and I encourage everyone to improve the code of Kismet. Some needs mentioned above could be solved with a microservice approach more generally though. This is exactly what EEWIDS tries to achieve. By creating a containerized framework EEWDIS enables

  • scalability
  • working easily in setups of bigger organizations
  • the possibility to add functionality easily (see below)

Main Idea of EEWIDS

Simple layout sketch of EEWIDS
Simple layout sketch of EEWIDS

Basis Kismet

EEWIDS uses Kismet as a basis. Thus, it uses Kismet’s advantages and tries to add functionality by using container techniques. As Kismet is under heavy development right now, EEWIDS uses the git version of Kismet right away, which is completely different to the last release from 2016. The Kismet remote capture (which replaces the former Kismet drone) is the only piece of software, which can not be containerized. The Kismet remote capture has to run on the machine which contains a Wi-Fi card which is able to monitor the traffic. As Kismet is very popular the Kismet remote capture will already run on many different machines and platforms, e.g. on OpenWrt. Therefore, it is better to use Kismet as a basis for capturing the data instead of building an own system.

The Kismet remote capture will send the data to a Kismet server instance which is running in a container. By using the Kismet server we will be informed about every attack which Kismet did detect and thus we can reuse the work already done on this side. EEWIDS will attach to the Kismet server to:

  • pull the pcap-ng data stream which contains all data captured
  • pull all alerts raised by Kismet server itself

Message Broker RabbitMQ

Both kind of information will be parsed and submitted to a Message Broker afterwards. The Message Broker is the central point of EEWIDS. By using RabbitMQ – one of the most popular systems of its kind – it is easily possible to subscribe to a needed information. This is supposed to be the big advantage for developers. Thus, instead of capturing and parsing Wi-Fi packets itself, a detection method only needs to subscribe to the needed information and will receive it directly from the Message Broker. Furthermore, the developer can use any programming language or system which is needed for this kind of detection, without bothering C++ or other stuff, which may would be necessary for Kismet plugins.

Analyzing and Visualization

The actual analyzing is done in services dedicated to this task. E.g. instead of parsing packages, looking for Beacons and analyzing it afterwards, a service will just subscribe to all Beacon frames. All other frames are not of interest. The service does not need to parse the Beacon frames, it just needs to access the json-formatted information it got from the Message Broker, e.g. data[‘wlan.ssid’] or data[‘wlan.bssid’]. This can be done independent of the programming language, as most of them already have modules for json and are able to access RabbitMQ. This setup should indeed work for every language which already has a client listed on RabbitMQ website.

Another advantage is the freedom of choice of visualization/analyzing software. It is easily possible to include either influxdata’s TICK stack or the elastic stack, both Open Source analyzing software which also have anomaly detection methods. These stacks and other software already have interfaces to access RabbitMQ and to read json-formatted data and thus it is easy to extract the collected information as needed.

This should make it easy to extend EEWIDS in various ways. Let’s see what can happen.

Focus

The usability on a developers perspective depends on the availability of logged frame information actually stored in RabbitMQ and the existence of easily adaptable templates. Furthermore, it has to be as easy and straight-forward to deploy the system as possible. That’s why I’d like to focus on three things:

  • the parsing of Kismet’s pcap-ng files should be as complete as feasable
  • there should exist templates for some major programming language to describe the usage
  • the deployment should work straight forward

GSoC 2018 – LibreNet6

Project Introduction

Community mesh networks often often lack IPv6 connectivity as their gateway connection can’t offer stable IPv6 addresses (which won’t change every night). A possible solution is to distribute bigger subnets via a tunnel connection between a server (or VM) and mesh gateway nodes. This approach already exists called LibreNet6. While the current implementation works, it’s hard to setup and only documented in Spanish language. Within this GSoC project the LibreNet6 stack should be simplified and better documented. Making it easier to install for server and gateway administrators and offer a more extensive documentation.

About me

My name is Paul Spooren and this is my second GSoC. Last year I worked with LibreMesh on an easy way to upgrade routers, even if opkg is missing. Beneath the GSoC I’ve worked on various parts of LibreMesh.

Project Requirements

  • IPv6 delegation: LibreMesh gateways use a specified IPv6 subnet of various size, depending on demand.
  • Server independece: If the IPv6 providing server goes down, nodes should keep connectivity also to the ones visible only trought LibreNet6.
  • Simple setup: The gateway operators should be able to install and receive IPv6 connectivity with as little manual configuration as possible.
  • Server interface: A simple administrative user interface should allow the management of assigned IPv6 subnets.

Current implementation

Currently the implementation uses the following software stack: * Tinc VPN: used to connect the gateway nodes with the IPv6 server. Also it’s used to allow inter mesh communication without using the servers. * Babel Routing Protocol: Used on top of the Tinc connection route between mesh gateways and server on the shortest path. * GitHub for authorized keys: All public keys of nodes authorized to connect to the mesh tunnel broker server.

Implementation ideas

  • The node setup should be installable as a package and provide the required information for connection via a simple web interface, favorable using the lime-app.
  • Using Babeld adds another routing protocol to the used stack, where most LibreMesh setups already use BMX6. It should be evaluated of BMX6 (or it’s successor BMX7) are a useable replacement.

Next steps

I’ll get access to a VM hosted by altermundi with an public IPv6 address. This will be a starting point to setup my own instance of Tinc and work on the interface. Apart from Tinc I’ll run some tests with Wireguard which might be a slim VPN replacement, even tho currently missing important features. Lastly I’ll check BMX{6,7} as a replacement for Babel (as it’s already used in most LibreMesh setups). Once these options are evaluated I’ll focus on creating an interface and packages to easily setup the whole stack!

GSoC 2018 – nodewatcher: Build system rework and package upstreaming

Who I am

My name is Robert Marko, I am 21 year old Computer Science student in Osijek, Croatia. I am active member of Otvorena Mreža, a partner organisation of Wlan Slovenija here in Croatia. Also, active member of OpenWrt project.

Project Overview

Like with most of the projects,mine has the following goals:

  • Simplification of the build system
  • Move from Ubuntu 14.04 as a base image to 18.04 to get the benefits from OpenWrt-s move to GCC7.3
  • Use OpenWrt generated image builders instead of building everything from source
  • Upstreaming and updating crucial project packages
  • Remove a number of hard coded outdated packages that are now provided by core OpenWrt

Bonding Period Experiences

I have already started working on my project by setting up the development environment with a deployment of Nodewatcher. Along the way I found out that installation was unfortunately broken so I fixed that and couple more bugs regarding packages used. I am now testing updates to newer versions of all Python packages used. Some of them were not updated for a couple of years.

First Goal/Milestone

My first goal will be to further analyze the build system as I am sure that some parts could be more optimised than in project proposal.

And then get to pushing packages upstream,that will most likely take the longest.

Best of luck to fellow GSOC students.
Robert Marko

 

 

A module for OLSRv2 to throughput estimation of 2-hop wireless links

Hi to community members!

This project aims to develop a module for the throughput estimation in OLSRv2 based networks. The basic idea is to evaluate the throughput of 1-hop and 2-hop network paths and to expose the measures to the user by visualizing them on the netjson graph.

The community bonding period had the goals to improve my knowledge of OLSRv2, to study OONF and its basic modules, then start approaching netjson. Now we are designing how to realize the throughput measures between the nodes. Basically, we are considering two approaches: the implementation of probe-based measure in OONF by using its reader/writer objects, or an alternative approach that realizes a daemon which reuses iperf based measures.

In the next weeks, we will update you with the initial results!

GSoC 2018 – RetroShare Web Interface Modifications/Improvements

Project Introduction

RetroShare, the encrypted peer-to-peer social networking system, has a web interface which makes it easier to use from multiple devices without running multiple nodes. The web interface works, but it is in need of improvements in its API, appearance, and user friendliness.

The web interface is particularly important to those who wish to use RetroShare heedlessly on a server, so they especially will benefit from improvements to it.

This project will mainly involve building on and redesigning the web interface API, libresapi.

Who I am

My name is Kevin Froman, I am a 19 year old American computer science student. I am passionate about online privacy, information security, and decentralized networking. I mainly have worked in web and mobile development, however I have some experience in standard desktop development as well.

More info about me, as well as a mirror of blog posts written here, is available at my website.

Project Overview

As with all projects, mine is made up of several main goals:

  • Switching the RetroShare web server library to Restbed (https://github.com/corvusoft/restbed)
  • Properly serializing all data in and out of the API as JSON
  • Refactoring and/or migrating existing code where applicable
  • Maintain existing supported RetroShare features in the UI (do not lose any in migration)
  • Add authentication (likely sha256-HMAC) to the interface to protect against certain browser attacks
  • Re-designing the front end, both style and functionality, likely using VueJS.
    • I am not a web designer, however I can definitely improve the appearance

Bonus goals include:

  • Adding more RetroShare features to the UI (the features the web UI supports is incomplete)
  • Making the web interface easier to setup on headless servers
  • External HTTP API mechanism with CORS (Cross Origin Resource Sharing)
The web interface’s appearance is currently not a work of art.

 

Bonding Period Experiences

Leading up to and during the Community Bonding Period, I got to know my mentors Cyril and Gio better and explored the RetroShare code base, especially libretroshare and libresapi. We discussed details about the project and the way project goals will be implemented.

As a way to dive into RetroShare, I worked on a backup system for RetroShare profile data to XML files. Unfortunately, I did not get a lot done on this, mainly do to final exams and projects for my classes which overlapped with most of the bonding period, but also due to roadblocks I ran into involving my development environment, personal issues, and less than optimal time management on my part. I felt I needed to spend time looking at libresapi and studying the code base in general, in order to be better prepared for the main coding period. The issues I had have been resolved.

At first, I found diving into this a large, multi-author code base intimidating, but I learned more of its structure and feel more confident for the main project.

First Goal/Milestone

My first project milestone is to fully analyze libresapi and to look for any code that should be kept/refactored and to finalize exact details of the new API system (white-boarding, prototyping, writing unittests). If all goes as planned, the first milestone will be done before May 28th.

I expect this goal to be accomplished early, so I will likely also be starting on the second milestone during this time, which is to get the base API system setup (both for the front-end and back-end).

 

I look forward to a summer working on RetroShare, and I believe my project will be a valuable contribution.

I wish the best of luck to fellow Freifunk GSoC students!

The Turnantenna

Intro

This year the “Battle of the Mesh” was hosted by the c-base community in Berlin. It was an awesome event, with amazing people coming from everywhere. I was able to present my project here, and it was exciting because many people was interested in. I also met some other students involved in the actual Google Summer of Code.

Unfortunately the week is over, and so is the bonding period.

Description of the project

Now it’s time to code, so let me introduce my project: The Turnantenna.

As its name suggests, the Turnantenna is a directional antenna paired with an engine that should be remotely controlled.

The advantages of having such a system are:

  • It could allow rapid changes of the mesh of the network;
  • It can make easy to dotests and optimization of the network;
  • It provides security as you don’t have to climb onto the roof (or pole, or pylon …) everytime, saving time and reducing dangerous operations.

Think about all the times that you had to reach the antenna to change it’s orientation. Now you can cut down this practice!

The Turnantenna was designed from and idea of Salvatore Moretti, another member of the Ninux community. With the other Ninuxers we made a working prototype of the Turnantenna, but now all the project should be improved.

The electrical scheme and a render are shown below.

The goal in the next month is to write down a new driver for the two engines, and to make them work through HTTP APIs. The orientation of the antenna will be changed interacting from a dedicated web page (that will be shaped in the next month) or sending HTTP requests; in the last month I’ll publish all the documentation and packaging the application with PIP.

Thanks

I wish to thank all the Freifunk members for the reception, and for giving me  the opportunity of being part of the Google Summer of Code this year.

I’d like to express my sincere thanks to all of the Ninuxers that helped and are still helping me in this adventure. I love you guys!