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.
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
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
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.
Concretely the auto generated IPv6 subnet (based on used network name) and the generated Tinc public key should be shown.
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!
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
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!
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!
Welcome! I’m Ferenc Fejes from University of Debrecen, Hungary. In 2017 I did my first GSoC project with my mentors Benjamin Henrion and Claudio Pisa. You can find all of my post from the project on this link here: https://blog.freifunk.net/tag/mptcp+lede/
In a nutshell it was an experiment to create a test-bed for aggregating the speed of multiple Wi-Fi links in transport layer with MPTCP. We succeeded, I also provided a detailed tutorial with the method for reproducing the experiment in home. I did not expected too much enquiry about the project but after the blogposts and an OpenWRT summit workshop, I received lots of emails and messages – many experimenter interested about the project which is a great honor of me. In China, where the router proxyfication is necessary because of the great firewall, many people applied the method of my GSoC 2017 project outcome. (Cont.) Continue reading “GSoC 2018 – Kernel-space SOCKS proxy for Linux”→
In 2018 Freifunk applied again as umbrella organization for Google Summer of Code. That’s the third year in a row and our 8th Summer of Code in total. Finally we got 14 slots for student projects.
Partner Organisations
As in the years before we act as umbrella organisation. Our partner organisations for this year are:
You can find our organisation’s profile and more information on our projects at the GSoC 2018 organisation’s page. This is just a list of our projects. More information will be added later when the coding period starts.
Titel
Student
Kernel space SOCKS proxy for Linux 4.x
Fejes Ferenc
Realizing a decentralized WiFi Controller
nick.power
Local Phone App
Daniel Dakhno
Easily Expandable Wireless Intrusion Detection System
Alexander Paetzelt
A module for OLSRv2 to throughput estimation of 2-hop wireless links
Pasquale Imputato
Design network agnostic communication protocol
Katharina Sabel
LibreNet6
Paul Spooren
nodewatcher: Build system rework and package upstreaming
Robert Marko
VRConfig – Visual Router Config for OpenWrt
Asco
LibreMesh ground routing user friendly interface
Marcos Gutierrez
RetroShare Web UI API Changes Proposal
Kevin Froman
Re-write the Turnantenna code
Marco Musumeci
Better map for nodewatcher
Marin Stević
OpenWLANMap App
Thi Huyen (Lilli) Cao
We’re looking forward for all these projects. Following the timeline we have the Community Bonding Period now. All students will be introduced to their organisation and their specific project. The projects will start latest at May 14. That’s when the coding period starts. There are several evaluations and the last Coding Period will end on August 6. After submitting the final evalulations by mentors and students the final results will be announced on August 22.
Stay tuned, all of the students will write about their project at this place. There will also be talks on events like the Wireless Meshup, Chaos Communcation Congress and other related events.
