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

 

 

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!

GSoC 2018 – Kernel-space SOCKS proxy for Linux

Background

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”

Our Projects for GSoC 2018

GSoC Logo

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:

GSoC 2018 Projects

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.

GSoC: Improving nodewatcher data representation capability(final report)

Introduction

This summer was really exciting because it was my first Google Summer of Code! I worked for Freifunk, a non-commercial initiative for free wireless networks. I would like to thank them for the opportunity to expand my programming skills and a great summer. I am excited that I got around to use Git on a serious multi-developer project and even create my first pull request. I developed a strong affection for Docker, which I now use for personal projects as well. After 5 years of programming in Python I am happy to add Django to my programming skill set. Continue reading “GSoC: Improving nodewatcher data representation capability(final report)”

GSoC: Libremesh Spectrum Analyzer – summary

Hello everybody!
This is my final report for GSoC 2017.
I have enjoyed this GSoC a lot. Having the chance to get involved with the LibreMesh development community has been a blessing, thank you Freifunk and GSoC for giving me this opportunity!
This months of coding for LibreMesh have allowed me to learn many new skills while being able to contribute to the common project and getting more involved in the governance and community of the project.
I have been working on many features and most of them have been merged to the LibreMesh main branch, so in the following pages you can find all the technical details of the work done.

Principal contributions

https://github.com/libremesh/spectrum-analyzer-packages

This repository contains all the code related to the spectrum analyzer.

It is also an OpenWRT/LEDE feed, so it can be added to a feeds.conf file to be used as a source of packages.

In this repository you can find:

  • Spectral Scan Manager: It manages ath9k states, recovers i/q data from the atheros modules and hands them over through ubus
  • Spectral Scan Decoder: FFT_eval wrapper that will receive Spectral Scan Manager i/q data and turn it into JSON
  • Spectral Analysis Collector: A configurable daemon that will collect the Spectral Scan Decoder data for further analysis. This collection could be kept in memory or sent to a secondary server (like the OpenPAWS server)
  • Visualization Module: Access the information handed by the Decoder or the Collector (depending which information we would like to access) and visualize it in a Waterfall graph.
  • OpenPAWS Server: OpenPAWS is an open implementation of the PAWS protocol, TVWS Database. The Spectrum Analyzer can talk to it to inform on the usage of TVWS frequencies.

https://github.com/libremesh/lime-packages

I had the chance to contribute some changes to the LibreMesh core, namely:

  • Adding the first steps of Continuous Integration and Continuous Deployment
  • Enhancing LibreMesh LuCI web interface

Outreach activities

As part of my involvement on the LibreMesh team, I got the chance to be part of many outreach activities to spread the word:

Things I had to learn

This were the things that I had to got deep into to get things done during the GSoC:

  • OpenWRT/LEDE Build pipeline
  • ath9k module functionality
  • LuCI module creation
  • Data visualization and D3.js Visualization tool

Reports on Freifunk blog

During my GSoC I did some articles about the life of a GSoC and LibreMesh/OpenWRT/LEDE programmer:

Things done

Things to be done

  • Proper packaging: right now the packages are not ready yet, so manual installation is required. I’m getting into this in the upcoming weeks.

    Variable frequencies: right now the Visualization Module only shows frequencies in the 5Ghz range. Refactor the code to be able to display all frequencies.

    Integration with LuCI: A LuCI module would be much more practical for integration with the rest of the architecture.

Future enhancements

  • Support for frequency shifters: there is a device that allows to do frequency shifting between 2.4Ghz and TVWS frequencies by connecting it to the radio conector.. Allow the system to be able to support it, namely, configure that there is one connected in a specific interface, and shift frequencies detected accordingly.
  • Add Support as an OpenPAWS agent: The scans done by this module could be used as an input for the OpenPAWS Server to monitor TVWS frequencies use and be able to handover frequencies based on current usage. For that, an agent needs to be developed that consumes the Spectral Analysis Collector data and sends it to the OpenPAWS Server.

Final Thoughts

The project has been very successful for me to get more deeply involved with the LibreMesh community.

Also, it helped me understand the complexity and diversity of knowledge required to engage with FLOSS projects.

Moving forward, I commit to continue working with the LibreMesh project.

Will continue mantaining the packages I produced and learning from the community to better serve it.

GSoC 2017 – wlan slovenija – Final report

What’s been done

The first blog post that describes the idea and goals can be read here, the first update here and the second one here.

So the Google Summer of Code came to a close. It was an interesting journey of learning, adapting and frustration. First I struggled with setting up the work space to work on LEDE platform. It was in the end successful and the whole process well documented, from setting up the virtual machines for running nodewatcher and nodewatcher-agent to actually coding, compiling and updating the agent with new packages. The end product is working HMAC signing of agent’s report messages that are sent to the nodewatcher. It can be used as a lightweight alternative to SSL certificates.

After that I tackled the task of improving the Tunneldigger, but was again met with deprecated documentation that wasn’t helpful at setting things up. After much struggle and digging around Slack I managed to get things going. Unfortunately my health disagreed and prevented me from finishing the task fully.

 

What’s next

If possible, I intend to finish the last task anyway so my contribution to wlan-si and Google Summer of Code is complete.

I am contributing using my github account.

Thank you for the great opportunity and good luck!