OpenWrt Device Page – GSoC 2021

Posted on by Aditi

Greetings everyone! 🎉

I am Aditi. And this summer I will be working on the project “OpenWrt Device Pages”. In this blog post I’d like to talk a little about me, my project and my first week!

About me

Hey!!👋
I am Aditi Singh, a Computer Science student from India. I have been studying programming since past 3 years.
After a little exploration, finally, out of so many appealing domains, I found the one for me – Web Development.
I’ve been working on web development for past 6 months. In January, I heard about open source from a college senior. The idea of writing hundreds of lines of code which can be used by thousands of people piqued my interest. The best part being people did it just for their love of coding and contributing to something bigger than themselves. So after a little bit of struggling with my impostor syndrome for a while, I gathered up the courage to start contributing to open source.

Open Source can be a little overwhelming to begin with but then it turned out to be an absolutely amazing experience. Never ever before I’ve had such a supportive and encouraging environment.
Later in March I found out about GSoC, and through GSoC came across – Freifunk. After surfing through hundreds of projects OpenWrt device page was that one idea that sounded fascinating to me and was closely related to my domain.

About OpenWrt

The OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable file-system with package management. It allows you to customise the device through the use of packages to suit any application. Hence, freeing it’s users from application selection and configuration provided by the vendor For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customisation, to use the device in ways never envisioned.

About OpenWrt Device Page Project

The main aim of OpenWrt Device Page Project is to create an overview of OpenWrt supported devices to simplify user choice of acquiring new devices. The goal is to evaluate the user needs and plan new device pages based on the user requirements to make it convenient for users to select right devices. Since, OpenWrt has a lot of data it becomes overwhelming for new users to find suitable devices that caters to their needs. So,to simplify the project can be broken down into two major sub-tasks:

  1. Creation of input form from a JSON Schema to simplify the process of adding device metadata to the github repository.
  2. After creation of input form, the second step is to render the device pages with search masks, allowing users to search specifically for devices with certain features like USB port, WiFi6 etc.

The first week of GSoC

After the community bonding period, we have been working on creating atomic tasks for the project along with the mentors with weekly milestones. The first task is to create a pretty input form to store device metadata into a github repository.
We have a basic input form ready from the JSON Schema implemented using React JSON Schema form. The RJSF community has been helpful in providing assistance to desired functionality. Upcoming major tasks include, modifying the input form to allow auto-fill and info button functionalities.

Apart from this I had to get an overview of Jekyll/Hugo functionality, understanding how YAML works to help with the project later on!

It has been quite a learning experience and I am looking forward to achieving more amazing things this summer with Freifunk! 🎉

Android native app for network selection capability in LibreMesh routers – Overview

Posted on by TomĂĄs Assenza

Hello! I’m TomĂĄs Assenza. I work on the “Android native app for network selection capability in LibreMesh routers” project with the Altermundi association. I’ll talk about what Libremesh is and why we want to make an app for network selection.

Introduction

LibreMesh is an operating system that works on some Tp-Link routers and LibreRouters, and It’s a practical solution to provide networks to social organizations. These social organizations usually give access to the web to users that only had mobile data networks before. The most practical object that they generally use is a smartphone to connect to the LibreMesh routers.

The issue

Android usually does a “network switch” between Wi-Fi and mobile data considering if the first one provides or not the Internet. The problem with this feature is that if the users have an internet problem, they would not have the possibility to access some LibreMesh internal address to know the trouble and report it to the organization.

We have the idea to solve this problem through an application with the capability To select from which network it sends and receives data from, making possible the connection between the smartphone and the router even when there isn’t an Internet connection.

Who am I? What are my motivations for the project?

I’m a System Engineering student at the Santa Fe Regional of the National Technological University (Universidad TecnolĂłgica Nacional – Facultad Regional Santa Fe). I work as a young teacher of the subject “Algorithms and Data Structures” and in two R+D projects, one about making software tools for programmers with visual disabilities and the other one about developing online simulators for the subject of ‘Chemistry’ by helping the students to experience chemical experiments even during the Covid-19 pandemic.

I always liked to learn how digital communications worked, but they also seemed far away from my profession and career. Considering this, I thought that the GSoC was an opportunity to learn new concepts and help communities with open-source software.

First meeting and objectives for this week

During the last week, we did a meeting to establish objectives for this week. These are:

  • Install the Android Studio IDE.
  • Make an application that can show the local address of the device.
  • Make an application that can show if the device is connected or not to the LibreMesh network (simulating through a ping to a random address).

And the results are:

  • App showing the local address of the device.
  • App showing that the device is connected to a LibreMesh network.

Github Project

Next objectives:

  • Change the ping-based detection.
  • Define a strategy to connect to the router in case that the app detects that the device is or not connected to the LibreMesh network.
  • Define the scope of the app

LibreMesh Pirania UI – An Overview

Posted on by Angie Ortiz Giraldo

About me

Hello there! I am Angie Ortiz Giraldo, one of the students selected for Google Summer of Code 2021, I’m very happy for have this opportunity and share this overview about my GSoC project. In this project I will be working with LibreMesh organization, a sub-organization of Freifunk in this GSoC. I am interested in software development and Community Networks environment. In this field, I have worked in different projects about Community Networks in Colombia that have implemented LibreMesh for their networks. For this reason, I am interested in improve and expand LibreMesh functionalities in some way.

About LibreMesh

LibreMesh is a modular framework for creating OpenWrt-based firmware for wireless mesh nodes. Several communities around the world use LibreMesh as the foundation of their local mesh firmwares. The project includes the development of several tools. The firmware is the main piece and allow simple deployment of auto-configurable multi-radio mesh networks. If you want to know more about LibreMesh you can go to the project website.

My GSoC Project

The main idea of this project seeks to improve the implementation of the administration interface of the Pirania captive portal which is implemented in LibreMesh, a plugin used in different Community Networks. I propose to divide the project in three important pillars: Solution design, Coding and Documentation. Every stage will have different task to do, and some deliverables.

Deliverables

  • Develop an UI proposal for the Pirania captive portal.
  • Plugin for the LimeApp that implements the UI with the required functionalities.
  • Coding tests for the functionalities implemented.
  • Write blog posts about different project stages.
  • Write documentation about features, and how to add plugins to Lime-App.

And more!

To sum up, this in a first approach about the project, but I hope to share some advances soon 🙂

Thanks for reading,

Angie.

[GSoC’21] Irdest Android Client – Overview

Posted on by Ayush Shrivastava

Hello everyone, I am Ayush Shrivastava, one of the students selected for Google Summer of Code 2021 for Irdest sub-organization under the umbrella organization freifunk. If you’re wondering which topic/project the blog is focused on, then you may give it a look here!

Irdest

Well, if you don’t know, then let me first introduce what Irdest(irde.st) is and what it does/supports. So, Irdest is a software suite that allows users to create an internet-independent, decentralized, wireless, adhoc mesh network. It removes all the dependencies of the user from a specific single service and enables users to create a mesh of their own. In this network mesh, users can communicate to each other via messaging(both, individual and Room) and placing voice calls. Irdest network mesh service also allows users to share files between them without relying on the internet. And also when a user enters the Irdest mesh network(note that user needs not connected to the internet i.e., without having an IP address, it can be a P2P connection over Wi-Fi or Bluetooth), their IP address is completely hidden thereby maintaining privacy andreducing possible breaches that may occur. In the irdest network mesh, as soon as a user enters the network, they are assigned an ID, which is a unique cryptographic key that helps identifying the users. All the messages/calls/file transfers made in Irdest network mesh are completely end to end encrypted, again a positive sign from security & Privacy perspective. Currently, Irdest is supported for Linux & Android devices. For android, it is pretty much in incubation state and there are a bunch of points & directions where we can improve. This summer, I aim to implement some features on android client from the irdest upstream.

WARNING: This blog has a tons of mentions of FFI, you may get overwhelmed by the term, so it stands for Foreign Function Interface.

Current Progress & FFI Overview

So this was what Irdest is all about and a higher level overview of how things really work in it. As mentioned previously, the android client is pretty much in its incubation state, so we wish to implement it in a clean & modern way. So, since we want to make use of features supported by Irdest(in upstream) on the android application, therefore we need to maintain/create a binding or kind of a link between core Irdest code that makes all this internet independent network mesh possible & application codebase(to call those methods from). The point is that the core Irdest code that supports these functionalities is written natively in Rust, and we we want to utilize this pre-written library on android, without writing it again(in Kotlin)for android. So to make it possible, we’re going to write an FFI Layer(I’ll write in detail about FFI in some other post, but for the time being it is sufficient to know that by FFI we can call functions written in a specific language(mostly native languages like C++, C, Rust) from some other languages). This FFI layer currently exists in the module, but it is a bit old-fashioned, so in the initial phase of my coding period I plan and propose to rewrite this layer with best possible modern day FFI practices and following some standard references. The most crucial part of this project is this FFI layer, because it is the fundamental building block for the android project, once it is set and ready, then we’ll be able to use the functions and services provided in the native Irdest library written in Rust and extend our further development process via writing the application.

FFI Implementation – A Blueprint

The FFI already is quite notorious for the undefined behavior and on top of it, there is very less official documentation available on Rust-Kotlin FFI so this makes it more tricky & challenging to implement, but for the course of our development process, we’ll be following and taking inspiration from how Mozilla have implemented FFI integration between their existing rust library and their firefox android client. Another instance where they use Rust-Kotlin FFI is their Glean project(a telemetry service). I’ll be taking most of the inspiration by and practices being followed in Glean, as a result of which we’ll be writing FFI bindings on our own. After once we’ve written FFI layer, my next step will be to test it again thoroughly and make sure it works perfectly and does not has any bugs residing.

Further Development:

Once we have a robust FFI layer ready, then I’ll move to core android development process, that’ll entail writing UI for the application, architecting it properly, modularizing the application codebase and following the Modern Android Dev practices. Well this will be a relatively easier job to do in comparison to that of writing FFI layer xD
My next step after this would be implementing the chat service in the application. We’ll focus in its detailing after we’re done with the very first milestone, the ”FFI Layer”. We’ll see the plan of action for chat service in a separate blogpost, after the first coding phase : )

Thanks for reading!
Cheers, Until next time we meet!

~Ayush Shrivastava

OpenWRT PPA @ Google Summer of Code 2021

Posted on by Neelaksh Singh
File:OpenWrt Logo.svg - Wikimedia Commons
Mentor : Benjamin Henrion

Hey everyone , hope everyone is doing fine. I am delighted to have been given this opportunity to work for OpenWRT project under Freifunk.

A little about myself

I am currently a sophomore at Birla Institute of Technology, Mesra. I have always been interested in the technical aspect of the world, as to how from the stroke of a keyboard does one get to build/execute such seemingly daunting tasks with such ease. 

The curiosity led me to the beautiful world of automation and containerisation along with managing these tasks at scale.

Apart from being a tech-nerd, I have always loved to explore the great mysteries of life, watch football, and play Golf among many others.

I am always ready to talk about the above at any time, so feel free to contact me.

Project Overview

OpenWRT is a Linux distribution for off the shelf Wi-Fi routers. People who want to make and distribute their personal packages, often for development purposes, so far have the option to build the whole firmware from zero, but very few people use the OpenWRT SDKs.

The idea behind this project is to provide the user with an interface where they can simply put in their GitHub repo URL, which can be then compiled and built into an executable Docker Image fit for Launch in k3d cluster, and also available locally.

Benefits to Community

This project will be beneficial for users since now they won’t have to build everything from scratch, and now only provide the URL of their source code.

Additionally, it will also try to achieve the following goals :

  • Autonomy: no external person is needed for the platform.
  • Build with many different targets like  brcm2708, ar71xx, x86, sunxi, etc…
  • Rebuilding after every commit can become possible.

And many more 
..

Deliverables

  1.  A front-end made using flask and python, where the user just needs to login and enter his/her repo URL.
  2. A backend made up using python and shell scripting for creating Docker Image based on the provided source-code.
  3. A database that stores this build docker image, made using MY-SQL database.
  4. A backend service integrating the above with k3d cluster for hosting docker container made using the container.

Next steps

I would be starting from implementing scripts for setting up the entire environment as well as working on the deployment of the newly created docker image on the local k3d cluster. I will also be in touch with my mentor , regarding the execution cycle and scope for improvement of the project.

Our Google Summer of Code Projects

Posted on by Andreas BrÀu
Google Summer of Code Logo

This year, we were finally accepted back as an organization at the Google Summer of Code. In the meantime, the application and selection phase is over. Google has given us 9 project slots. We didn’t make the decision easy and chose the best ones out of the applications.

Organizations

Freifunk manages projects for different initiatives as an umbrella organization. In this Google Summer of Code we have Retroshare, irdest, OpenWrt, LibreMesh and freifunk itself on board.

Timeline

Currently we are in the community bonding period. During this time, all preparations are made so that the students can do their tasks. Also, they should dive into the communities and get to know people and tools.

Coding officially starts on June 7. All projects must be completed by August 23.

Our Google Summer of Code projects in 2021

TitleOrganizationStudent
OpenWRT PPAOpenWrtNeelaksh Singh
Irdest Android ClientirdestAyush Shrivastava
Android native app for network selection capability in LibreMesh routersLibreMeshTomĂĄs Assenza
RetroShare WEBUIRetroShareAvinash
Freifunk Digital Twin – test on your virtual mesh before going productiveOpenWrtpschreiber
OpenWrt Device PageOpenWrtAditi-Singh
Freifunk Radio Ressource Management with IEEE 802.11vOpenWrtValerius_B
Updation of the Json Schema to latest version (2020-12) along with the form generation and validation with the updated schema of the toolsfreifunksh15h4nk
LibreMesh Pirania UILibreMeshAngie Ortiz Giraldo

You can find more details for every projects on our GSoC dashboard.

Freifunk @ Google Summer of Code 2021

Posted on by Andreas BrÀu
GSoC Logo

Apply now at https://summerofcode.withgoogle.com/

What is Google Summer of Code (GSoC)?

Google Summer of Code is Google’s summer program for students to learn about, and get involved in open source. It’s happening again for the 17th year in 2021! Over 16,000 students from 111 countries have participated.

Freifunk got accepted as umbrella organization for wireless network communities like Ninux, qaul.net, Guifi.net or WLAN Slovenija and communities developing software we extensively use like OpenWRT, OLSR, BATMAN, libremesh or retroshare. See our GSoC’s profile page for more information.

The goals of the program are to:

  • Motivate students to begin participating in open source development.
  • Help open source projects bring in new, excited developers into their communities who stay long after their GSoC ends.
  • Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits.
  • Give students exposure to real-world software development scenarios (e.g., testing, version control, software licensing, mailing-list etiquette, etc.).
  • Create more open source code.

How does GSoC work?

Programming online from their home, student participants spend 10 weeks on their projects (about 175 total hrs) earning stipends upon completion of their milestones. Volunteer mentors help students plan their time, answer questions and provide guidance on best practices, project-specific tools, and community norms while helping integrate students into their communities.

Students receive an invaluable learning experience, an introduction to the global FOSS community and something that potential employers love to see on resumes!

Mentoring orgs will gain new contributions & contributors along with recognition from Google and a higher profile for their project.

How to apply for freifunk @ GSoC 2021?

  1. Pick an idea from our projects page and get in touch with mentors and the community.
  2. Discuss your ideas and proposals.
  3. Submit a draft of your proposal early, so we can give you feedback.
  4. If you have any general questions, join our Matrix room.

Student applications are open March 29 – April 13, 2021.

Who can apply?

In short: you have to be at least 18 years when you register and you need to be enrolled in or accepted into a post-secondary academic program, including a college, university, masters program, PhD program, undergraduate program, licensed coding school. For all details, please see GSoC’s FAQ.

Infos zum Sicherheitsvorfall im Freifunk-Wiki

Posted on by Malte

Am 23.04.2020 wurde auf dem Server von wiki.freifunk.net ĂŒber eine SicherheitslĂŒcke weitere Software installiert, die anscheinend auf anderen Servern nach Ă€hnlichen SicherheitslĂŒcken gesucht hat. Am MediaWiki selbst wurden soweit ersichtlich keine Änderungen vorgenommen oder Daten abgefischt. Der Zugriff blieb anscheinend auf den Webserver-Benutzer begrenzt. Da Analysen in der Richtung aber keine 100%ige Sicherheit bieten können, sollten alle Menschen mit Wiki-Accounts ihre Passwörter dort Ă€ndern, auch wenn die Passwörter in der Wiki-Datenbank nach Stand der Technik sicher als Hash abgelegt sind (pbkdf2/sha256). Diejenigen, die sich seit dem 23.04.2020 neu registriert haben, wurden von uns gesondert informiert. Das Wiki nutzt Accounts nur zur Abwehr von Spam und bietet keine persönlichen PostfĂ€cher oder Ă€hnliches, entsprechend liegen im Wiki keine personenbezogenen Daten abseits vom gehashten Passwort (und ggf. E-Mail-Adresse) vor.

Vermutlich war das Wiki “Beifang” bei einem grĂ¶ĂŸerem Hack von WordPress-Webseiten im Rahmen der Traber- und SSSP-Kampagnen.

Der Hack wurde am 27.04.2020 bemerkt, das Wiki offline genommen, der Rechner komplett neu installiert und die Datenbank aus einem sicheren Backup aus der Zeit vor dem Hack wiederhergestellt. Am 30.04.2020 ging die neue Installation online.

Technischer Hintergrund

Als Einfallstor wurde PHPUnit benutzt, das versehentlich als Development-Dependency via PHP Composer installiert wurde. Composer installiert AbhĂ€ngigkeiten im “vendor”-Verzeichnis, das in der installierten alten MediaWiki-Version von außen zugĂ€nglich war.

Es kamen also mehrere Faktoren zusammen:

  • Der Code in PHPUnit ist gelinde gesagt “ĂŒberraschend” (und wurde vor wenigen Monaten dort auch entfernt)
  • Verzeichnisse mit internem Code waren nach außen sichtbar (das wurde in MediaWiki vor einiger Zeit per .htaccess behoben)
  • Composer installiert in der Voreinstellung auch Developer-AbhĂ€ngigkeiten
  • Wir haben die Software nicht regelmĂ€ĂŸig aktuell gehalten. Leider ist das angesichts von AbhĂ€ngigkeiten wie dem Freifunk-Skin nicht immer ganz einfach.

Maßnahmen

Der Prozess zum Einrichten und Aktualisieren des Wikis wurde weitgehend automatisiert. Wir werden das Wiki in Zukunft aktuell halten und im Zweifelsfall AktualitÀt der Software höher priorisieren als FunktionalitÀt wie das Skin.

Zur Vermeidung von Datenhalden werden in Zukunft komplett ungenutzte Accounts automatisch gelöscht bzw. inaktive Accounts nach einiger Zeit deaktiviert und die diesen Accounts zugeordneten Passwort-Hashes und E-Mail-Adressen aus der Datenbank entfernt.

Beim Erstellen von Accounts wird jetzt darauf hingewiesen, ein sicheres Passwort zu setzen, das fĂŒr keinen anderen Dienst benutzt wird.

Vielen Dank an alle, die sich schnell gekĂŒmmert haben und halfen, die SicherheitslĂŒcke schnell zu schließen.

36C3 in Leipzig – Freifunk Assembly im OIO – Open Infrastructure Orbit

Posted on by R3tt3r

Wie erwartet hatten wir auf dem 36C3 eine tolle Zeit und sind uns einig, dass man das alte Jahr kaum besser beenden kann, als mit Gleichgesinnten die Nacht zum Tag zu machen und sich mit Mate oder Tschunk in der Hand auszutauschen.

Aber nach dem 36C3 ist vor dem 37C3 und damit uns keine Post-Congress-Depression packt, haben wir ‚Refreshing Memories‘ betrieben und keine ‚Ressource Exhaustion‘ vorgenommen. Anfang der Woche trafen sich Interessierte, die wir zuvor ĂŒber das Freifunk Forum und die Mailingliste WLAN News eingeladen hatten, in einem Mumble. Wir haben offen besprochen, was gut gelaufen ist und wie wir unsere Freifunk Assembly auf dem nĂ€chsten Congress noch spannender und fĂŒr alle Beteiligten besser gestalten können.

Los geht‘s mit einer kurzen Intro.

Warum eigentlich OIO?

Das OIO bietet allen Freifunk Communities einen galaktischen Orbit um

  • Projekte vorzustellen
  • vor Ort Projekte mit anderen Freifunker*innen zu realisieren
  • Freifunk Themen zu diskutieren
  • Miteinander eine gute Zeit zu haben
  • Neue Projekte zu entwickeln

Wer hat mitgemacht?

FĂŒr den 36C3 haben sich regelmĂ€ĂŸig 3-4 Communities aktiv an der Orga der Freifunk Assembly beteiligt und eingebracht. Auf dieser Grundlage haben wir die Entscheidung fĂŒr 2 Schiffe mit ingesamt 24 SitzplĂ€tzen getroffen.

Ein paar Zahlen

Das OIO Orgateam hat vor Ort in Leipzig rund 670 Stunden (!) in Bau des Hafens, der Schiffe, des Leuchtturms auf dem Felsen, des Workshop-Domes und der OIO-Stage gesteckt. DafĂŒr noch einmal Respekt und ein dickes Dankeschön!!!! Auch wenn wir viel vom letzten Jahr wiederverwenden konnten, mussten Bauteile und die schicken Flaschenlampen neu produziert werden. FĂŒr die Veranstaltungstechnik sind weitere Ausgaben angefallen und auch unvermeidliche Transportkosten schlugen zu Buche. Per 26.01.2020 fehlten noch 1.900,42 € in der Kasse und somit folgt ein ernst gemeinter

Spendenaufruf

Wir bitten jeden Menschen und vor allem die Freifunk Communities darum, sich an der Spendenaktion unter http://spenden.oio.social/ und dort unter 36C3 OIO – Open Infrastructure Orbit zu beteiligen und ein paar Taler beizusteuern. NatĂŒrlich sind diese Spenden steuerlich abzugsfĂ€hig und helfen dabei, das die Freifunk Assembly auch beim 37C3 wieder in dem sicheren OIO Hafen anlegen kann ;-).

Nachbrenner und Fazit aus dem Mumble

Aktive Teilnahme

Fangen wir mal offen und selbstkritisch damit an wie es um die aktive Teilnahme von FF Communities an der FF Assembly im OIO bestellt war. Leider waren es nur wenige und wir haben gelernt, dass es grundsĂ€tzlich nicht an Interesse oder Motivation mangelte. Vielmehr waren die im Vorfeld zum 36c3 gewĂ€hlten InformationskanĂ€le nicht ausreichend bzw. nicht umfassend genug und mĂŒssen in Zukunft noch stĂ€rker und regelmĂ€ssiger mit klaren Informationen bespielt werden, damit sich mehr FF Communities aktiv an der FF Assembly im OIO beteiligen.

In 2019 haben wir diese InformationskanÀle genutzt:

ZukĂŒnftig werden wir zusĂ€tzlich noch folgende KanĂ€le fĂŒttern:

WĂŒnschenswert ist, dass die lokalen Communities auf ihren Seiten mit aktuellen Hinweisen auf den 37C3 / OIO / FF Assembly verweisen und ihre eigenen Social Media KanĂ€le nutzen, um diese Informationen weiter zu verbreiten.

Inhalte

Gut informiert sein heißt nicht, ein wenig von Allem zu wissen, sondern alles von den Dingen auf die es ankommt. Wir Organisatoren haben offensichtlich nicht klar genug kommuniziert, dass das OIO allen Freifunk Communities einen galaktischen Orbit bietet, um Projekte vorzustellen oder solche vor Ort mit anderen Freifunker*innen zu realisieren.

Weiterhin bestand offensichtlich Unklarheit darĂŒber, dass wir uns aktive Mitarbeit in der Freifunk Assembly „im Hafen des OIO“ von allen wĂŒnschten, die sich fĂŒr einen Voucher unter https://wiki.freifunk.net/36c3/Participants gemeldet haben.

Offensichtlich war auch die von uns im Wiki gewĂ€hlte Formulierung „sich mit anderen einen Sitzplatz teilen möchten“ wohl zu schwammig und fĂŒhrte zu leichten Spannungen auf dem Congress aufgrund unterschiedlicher Erwartungshaltungen. Das Orga Team hatte feste SitzplĂ€tze fĂŒr alle aktiven Beteiligten einkalkuliert und kam so auf 2 Schiffe mit insgesamt 24 PlĂ€tzen. Viele passive Participants sind allerdings davon ausgegangen, dass ein Voucher auch automatisch einen festen Sitzplatz beinhaltet.

Das werden wir in 2020 besser machen. FĂŒr den 37C3 werden wir eine noch genauer zu definierende prozentuale Verteilung aus Named-Seats (also mit klarem Personen & Community Bezug) und Shared-Seats (nicht reservierbar) haben. Bei den Shared-Seats wird somit auch das Kleben eines Community Stickers auf dem Tisch oder das Stehen lassen eines Laptops nicht zu einem dauerhaften Sitzplatzanspruch fĂŒhren. SelbstverstĂ€ndlich werden wir alle Inhalte verbessern und versprechen heute schon eine klare und regelmĂ€ĂŸige Kommunikation.

Auch die entsprechenden AbsĂ€tze/Formulierungen in den Vouchercode-Mails und die Mailingaktion hinsichtlich Spendenaufruf und CallForParticipation an die „erfolgreichen Vouchercode-Nutzenden“ hatte leider kaum einen erkennbaren Erfolg.

Brainstorming

Wir haben in die Runde gefragt, was sich alle Beteiligten wĂŒnschen und woran wir beim kommenden Congress denken sollen.

  • Mehr Beteiligung beim Auf- und Abbau von allen Communities und Freifunker*innen
  • Spendentrommel stĂ€rker und frĂŒher rĂŒhren
  • Spenden von FF Vereinen gesondert erbitten
  • Spendenhöhe empfehlen- z. B. X € pro Person
  • Verweis auf steuerliche AbzugsfĂ€higkeit von Spenden unter spenden.oio.social
  • Fördergelder ĂŒber Freifunk Landesförderung NRW beantragen – Beispiel: FF Community X stellt Projekt A vor und dafĂŒr wird eine AusstellungsflĂ€che mit X SitzplĂ€tze benötigt, hierdurch entstehen Kosten in Höhe von X € und deshalb wird durch die FF Community X ein Antrag auf Förderung beim Land NRW gestellt.
  • Voucher in Verbindung mit Spendenaufruf
  • stĂ€rker an Freifunk Assembly AktivitĂ€t koppeln, aktive Teilnehmer*innen werden somit bei der Vouchervergabe bevorzugt, denn aufgrund der VielfĂ€ltigkeit der anfallenden TĂ€tigkeiten kann jede/r etwas Aktives beitragen

Wiki wird mit klaren Formulierungen entsprechend aktualisiert.

Ideensammlung

Das Beste kommt zum Schluss! Hier sind Eure Ideen was wir diesen Jahr zusÀtzlich machen sollen:

  • Analoge Community Karte aufhĂ€ngen – GrĂ¶ĂŸe: 2 * A0
  • Freifunk Logo auf geeignete große plakative Stelle drucken/sprayen /projizieren
  • Freifunk von erhöhter Stelle auf den Boden als „bewegtes Logo“ projizieren
  • Freifunker*innen in einer Vorstellungsrunde persönlich kennenlernen – Domo “mieten” – loser Austausch ohne definierte Themen
  • FF Projekte / Inhalte vorstellen und ĂŒber alle KanĂ€le kommunizieren
  • Projekte vorbereiten, die explizit auf dem Congress bearbeitet werden (Arbeitsgruppen, Workshops), um dort auch zu Arbeitsergebnissen zu kommen.

Vielen Dank an alle die mitgemacht haben und auch in Zukunft mitmachen werden.

FĂŒr das ganze Freifunk Assembly Orga Team

Adri – FF EN

LaLa – FF EN

R3tt3r – FF Neanderfunk

LingLing – Fichtenfunk

BMX7 – WireGuard Tunneling: Final Report

Posted on by Harry Pantazis

It has been a wild ride and this post marks the completion of GSoC 2019 for WireGuard Tunneling in BMX7. Throughout the summer a lot of effort has been put into coding, documentation and codebase restructuring; it has been a appetizer for what awaits us coming Autumn.

  • My fork can be found here.
  • WireGuard Plugin branch can be found here.

Overview

During the final phase of GSoC 2019, focus has been put into recombining what has already been done. An ideal goal had been to extend the wg_tun plugin functionality with the routing of traffic between associated peers, but this remains a work in progress. Testing has taken place and quite a few SIGSEGVs have monopolized interest. Also, research has been contacted on whether and how to cryptographic primitives used in BMX7 and WireGuard. This seems infeasible currently, due to the differences between cryptographic keys of the two.

Here we see the successful communication between two bmx7-wg nodes and their association; of course while in testing SIGSEGVs are out to hunt you.

The wg_tun Plugin

Our ultimate and prime goal has been the beta release of this plugin. The plugin offers BMX7 the capability of setting up an iproute2 WireGuard device interface with a unique pair of keys that is automatically looking for all available peers and establishes a connection with them.

In the current approach we have designed along with Axel an approach about the unique cryptographic address assigned to the wg interface (a concept similar to the existing), where the BMX7-WG auto-configured IPv6 address is a product of the unique prefix fd77::16 and the first 14 bytes of the node’s SHA224 hash. Research goes on in this to figure out the best approach (network and cryptography wise).

In the past days we saw the creation of wg_status option and the addition of debug flags to inform an administrator of the state of his WG device (related commit).

At this stage, testing is being performed to analyse the behaviour of the plugin after the associations among peers and include more status information and more options for the control of the plugin by the user.

The “misses”

Of course when you go too optimistic into the dark something’s gonna not work out.

In this project the misses can be summarized in: devoting more time than initially expected into studying and researching and dropping some core goals for the sake of more important ones.

The goals we “skipped” have been the Debian Package and the refactoring of Mesh Linux Containers to aid with testing.

In the studying part, I was supposed to devote only the community bonding period and part of the first phase to study white paper and get up to speed with theory between what needed be implemented and fiddled. I ended up devoting time throughout all the phases, but I’m happy with what I’ve learned.

Further Work

The intention to continue work on BMX7 is trivial to answer. GSoC has been a good experience and way to get started with the codebase of BMX7, but free flowing, detrimental work is scheduled for after it.

Final Thoughts

I’m very happy I got the chance to help Freifunk’s goals and hope to continue however I can.

Battlmesh V12 was super nice and I look forward to next year’s (I hope it’s Netherlands).

At last, I would like to thank my mentors Paul Spooren and Axel Neumann for their advice and way they approach cooperation.