DAWN – A decentralized WiFi Controller

Hi,
I’m Nick. I study Computer Engineering at the TU Berlin. It is my first time participating in Google Summer of Code. I am realizing a decentralized WiFi controller.

DAWN is the first decentralized WiFi controller for OpenWrt. The controller provides access to valuable information, e.g., all connected stations, their capabilities, and information about all participating nodes. Moreover, DAWN provides load balancing to increase the network performance by controlling the clients association.

What’s missing?
An important aspect of the controller is the simple installation. Everybody, even people with limited technical knowledge, should use this controller to increase their network performance at home. Until now, DAWN requires a special patched OpenWrt to run. So a user needs to compile his own image. The first thing I have to do is to bring the last patches upstream. Some of the patches were rejected and that is why I have to rewrite different functionality and create new pull requests. Furthermore, I have to extend the libiwinfo library to get all necessary informations from the OpenWrt system.
After this, the configuration of the nodes should be simplified. So far, the user has to configure all participating nodes individually. I want to implement some bootstrapping to automatically configure the participating routers.
After simplifying the installation and configuration, I want to visualize the information of the participating nodes with a graphical user interface.
The last step is to improve the controller functionality by adding mechanisms like a channel interference detection and other useful features. Moreover, this step contains to improve the load balancing.

In my next blog post, I will write about why some of my OpenWrt patches were rejected, how I have to extend the libiwinfo. However, if this steps are successful everybody will be able to simply install DAWN without the need to patch OpenWrt.

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.

Meshenger – P2P local network messenger

Hi, my name is Daniel, I am a 19-year-old student from Augsburg, Germany, and I have been working with Android and networking for several years now.

Thus, i am very excited to participate in the GSoC for the first time, hoping to learn new ways of connecting people with “Meshenger”.

The goal is to make an app, which allow audio- as well as videocalls through a local network, not requiring a server.

The signaling, e.g. the exchange of nessecary network-related information will then happen through the scan of a QR-code generated by one of the connecting devices.

Of course there are several challenges i will have to tackle, like having to get WebRTC running without a STUN-server, which is normally required.

 

In the next post i will share my progress as well as my collected experiences, explaining my approaches and trade-offs that will eventually have to be made.

 

Project source: https://github.com/dakhnod/Meshenger

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

Introduction: OpenWLANMap App

Hi,

My name is Lilli and I am studying technical computer science at the 6.th semester in Hamburg, Germany. In this summer, i will work on a new wardriving app for openwifi.su

OpenWifi.su is working on wifi positioning system. It uses an android app called OpenWLANMap App as the wardriving tool to collect wifi access points and sends it with the geolocation of the phone to the backend. The backend stores the data in database and also offers an API for non-GPS devices to request their positions based on the surrounding wifis.The backend currently uses triangulation technique on the numbers of access points it receives from the request device to calculate it’s geolocation.

A data entry from the wardriving app is currently BSSID + LATITUDE + LONGITUDE, which is stored temporarily effectively in local disk with 28 bytes (12 bytes for 12 characters of the MAC Address, 8 bytes for each latitude and longitude) before being uploaded to backend. The wardriver can do it manual or automatically. The app respects _nomap Wifi APs and does filter out some mobile hotspots on public transportation in europe. Unfortunately the app is hardly out of date. There are no developers working on the app and no updates for years. It does not run in new android devices. The OpenWifi.su has an amazing community of wardriver, over four thousands people. They have to keep very old phones to be able to run the app. But this community began to shrink in fact because peoples buy new phones which are not able to run the old app anymore.

I am so glad to get involved in the project and can spend my Google Summer of Code rewriting the app. Thank to freifunk community I was allowed to participate in the Wireless Community Weekend in Berlin in the community bonding period and had the chance to present my project, as well as talk to people about it and possible solutions for many problems. I spent the last weeks analysing the old app code and was talking a lot with my mentor about the old app performance and functionalities and ended up with many important decision about the design for new app. Here are some of them

  1. Wlocator is a service of getting GPS either from the device itself. In worst case where the GPS is undefined, it will send a request with the surrounding wifis to the Openwifi.su backend to ask for it’s geolocation. The service will run every n seconds
  2. Wifiscan is a service of scanning wifi access points. All the data of the AP such as BSSID, SSID, RSSI, frequency, channel , encrypted method, scan timestamp etc. will be scanned and display as user’s option. Necessary data will then be stored temporally local and later on uploaded to the database. The service will be stopped if the GPS of the device isn’t changed after n seconds in order to save device’s battery.
  3. Wififilter helps filter out: _nomap, mobile hotspot ( Call for help to collect mobile hotspot from different countries), ad_hoc network (I am working on it), collect open wifi to automatic connect and upload data if possible.
  4. Use trilateration or other techniques to define the location of the scanned AP better
  5. WifiUpload let users upload the data manual, automatic if internet available, automatic if only wifi available
  6. Extension: upload data to different APIs
  7. Saving resouces: stop scan service after n second of not changing GPS, put app in standby/doze mode if GPS does not change after n second, reduce brightness, kill app if battery critic
  8. Different languages available
  9. etc.

The plan for the next three months will be:

  1. Design new architecture for new app functionalities
  2. Design new UI
  3. Implement all logic functionalities
  4. JUNIT test + documentation

Stay tuned, I will update it soon.

L3I2

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