Neue Fimware für Freifunk Bielefeld

Nach über 8 Monaten Entwicklungszeit und über 300 Commits ist jetzt die neue Firmware (Version 0.4) von Freifunk Bielefeld fertig! :D

Innerhalb der Firmware wurde vieles stark umgebaut, sodass wir jetzt besser für die Zukunft gerüstet sein sollten und der Verwirklichung eines freien und dezentralen Bürgernetzes einen weiteren Schritt näherkommen

Ein paar wichtige Änderungen im Detail

Die Namen und Positionen der Router werden jetzt auf dem Router eingestellt anstatt über das Knotenformular auf unserer Webseite  und ermöglicht damit eine dezentrale, gleichberechtigte Kartengenerierung. Nun kann der Router auch so eingestellt werden, das er nicht zur Kartengenerierung beiträgt und daher unsichtbar ist. Ebenso werden auch endlich nicht mehr die MAC-Adressen der Clients (die blauen Punkte) für die Karte übertragen, sondern nur die Anzahl.

Die größte Änderung betrifft die komplette Umstellung auf IPv6. IPv6 soll in Zukunft auch im Internet IPv4 ablösen. Wir gehen diesen Schritt schon jetzt.  Ein Vorteil ist, das nun auch Geräte innerhalb des Freifunknetzes aus dem Internet heraus erreichbar sind. Den allermeisten Nutzern sollte diese Umstellung aber normalerweise nicht weiter auffallen. Bei alten Geräten kann es aber zu Problemen kommen. In dem Fall versuchen wir aber gerne zu helfen.

Eines der großen Probleme im Freifunknetz ist das Auffinden von internen Diensten. Das kann z.B. eine Webseite sein, ein Spieleserver oder WebCam. Daher kann nun auf der Weboberfläche des Routers ein Link eingegeben werden, der auf allen öffentlichen Statusseiten der Router angezeigt wird.  Dies soll helfen, die Nutzung von internen Diensten anzuschieben. Standardmäßig ist die Anzeige auf dem Router allerdings ausgestellt.

Bitte beachtet, dass das Autoupdate erst in ein paar Tagen zur Verfügung steht und bis dahin die alte Karte auf dieser Seite eingebunden ist. Die Downloads sind aber bereits verfügbar und neue Knoten tauchen jetzt auf der neuen Karte auf.

 Liste der Änderungen
  • Wechsel auf OpenWrt Barrier Breaker (14.07)
  • IPv6 only mit NAT64/DNS64 auf den Gateways
  • Jeder Router verteilt ein gemeinsames FF-lokales Prefix für isolierte/autarke Netzwerke
  • Unterstützung neuer Modelle
    • u.a TP-LINK CPE210/220/510/520 (danke an Gluon)
  • Mesh-Protokoll: batman-adv 2014.4.0
  • VPN zum Server: fastd v17
    • höhere Geschwindigkeit und Sicherheit
  • Der WAN-Anschluss kann jetzt mit den Ports und einem privaten AccessPoint gebridged werden.
  • Die Kartendaten (Name und Position) können auf dem Router eingetragen werden.
  • dezentrale und gleichberechtigte Karten (mit alfred und ffmap)
  • Die Firmware/Karte unterscheidet jetzt verschiedene Communities
  • Karte: ffmap unterscheidet jetzt unterschiedliche Communities in einem Netz
  • Die Weboberfläche des Routers wurde neu gestaltet
  • Jeder Router kann einen Service verkünden (Label+Link), welcher auf den Statusseiten der anderen Router angezeigt wird.
    • Per default ist die Anzeige au der Statusseite dekativiert
  • Inkognito-Modus des Routers – übermittelt keine Daten für die Karte.
  • Die Identität des Routers (MAC-Adresse) kann über die Weboberfläche gändert werden.

 Screenshots

Fertige Images sind wie immer auf unserer Downloadseite zu finden. Die Quellen der Firmware und zum Betreiben eines Servers/Gateways befinden sich auf github.com.

Danke an alle, die dieses Release ermöglicht haben und mitgeholfen haben unser gemeinsames Netz voran zu bringen!

VPN als Dienst im Weimarnetz

Im Weimarnetz wird VPN für zwei Zwecke genutzt: Die Verbindung von Meshwolken, die sich durch die Luft nicht sehen können und um die DSL-Betreiber aus dem Fokus der Abmahnanwälte zu nehmen. Sollte die Störerhaftung fallen, geht es nur noch um die Verbindung der Wolken untereinander. Jahrelang haben wir das gesamte Netz mit einem (zentralen) Server betrieben. Ergebnis langer Überlegungen ist ein dynamischeres, offeneres Konzept, das wir nun umzusetzen wollen.

Was möchten wir erreichen?

  • Jede_r soll einen Server im Netz bereitstellen können, ohne die Konfiguration anderer Server oder Router ändern zu müssen.
  • Server sollen dezentral und organisatorisch unabhängig voneinander arbeiten. Wir wollen nicht von Einzelnen abhängig sein.
  • Lastverteilung und Ausfallsicherheit über mehrere Server
  • die Bereitstellung eines VPN-Servers soll im besten Fall scriptbasiert möglich sein
  • das Hinzufügen oder Austauschen von Servern funktioniert ohne, dass wir die Firmware auf den Routern anpassen müssen. Das Konzept soll möglichst wenig Dienste auf Server und Router erfordern (idealerweise nichts, was über OLSR und VPN hinausgeht, Internet setzen wir mal voraus)

Wie funktioniert es?

Server

Auf Serverseite benötigen wir vtun als VPN-Software und OLSR als Routing Daemon. Beides kompilieren wir selbst, da die Pakete in den Linuxdistributionen hoffnungslos veraltet sind (insbesondere OLSR) oder nicht zu unseren Anforderungen passen (vtun). VTUN kann in verschiedenen Varianten angeboten werden, die Parameter sind (de)aktivierte Verschlüsselung oder Kompression. Die unterschiedlichen Ausprägungen von VTUN müssen auf verschiedenen TCP-Ports lauschen. Weimarnetzrouter laufen standardmäßig ohne Verschlüsselung und ohne Kompression.

VTUN wird auf einem Server so vorkonfiguriert, dass sich jeder Knotennummer (=Abstraktion der IP-Konfiguration) aus dem Weimarnetz mit dem Server verbinden kann. Der OLSR-Dienst startet bei einem noch unbekannten Router kurz neu, um diesen in die Konfiguration aufzunehmen. Der Clou ist, dass sich der VPN-Server – selbst ein Knotenpunkt im Mesh – per OLSR-Service-Plugin im Netzwerk als Dienst ankündigt und so auch andere Router von diesem Dienst erfahren. In dieser Meldung teilt der Server Verbindungsdaten mit, z.B. die Ports, die MTU oder die Anzahl der bereits verbundenen Router.

Untereinander können sich die Server ebenfalls verbinden und das Mesh erweitern. So wird vermieden, dass Inseln entstehen.

Router

Jeder Router pflegt eine aktuelle Liste angekündigter VPN-Dienste. Die ist fest gespeichert, um einen Neustart zu überleben. Auch im Fall, dass andere Meshnachbarn fehlen, sind trotzdem Informationen zu verfügbaren Diensten da und eine Verbindung kann initiiert werden.

Stellt der Router fest, dass er selbst über Zugang zum Internet verfügt wird versucht, eine VPN-Verbindung zu starten. In einem kurzen Test wird der am besten erreichbare Server ausgewählt (z.B. Ping-Zeit, Anzahl Clients) und eine Verbindung mit diesem gestartet. Fertig.

Wie sieht es heute aus?

Wir haben inzwschen 3 laufende Server. Einen stellt uns Ufo aus Leipzig zur Verfügung, Basti betreibt einen in Chicago und einen in Düsseldorf. Einer unserer Mitstreiter baut gerade einen Server in der Schweiz auf, den wir dafür auch nutzen dürfen.

Aktuell laufen die Arbeiten an der Integration der Funktionen in unsere Firmware, die ersten Tests sehen vielversprechend aus.

Eine Note zu freifunk

Es war Anfang der 2000er Jahre, als drahtlose Netzwerkenthusiastinnen in Leipzig zusammen kamen, um sich gemeinsam über die Gründung eines offenen Meshnetzwerkes auszutauschen.

Die Idee war ein Fensterbrett-zu-Fensterbrett Netzwerk, das Menschen nachbarschaftlich verbinden sollte. Wir wollten eine eigene Netz- und Infrastruktur aufbauen, die sich aus billigen WLAN-Routern zusammensetzte, die von einzelnen, auch anonym, betrieben wurden.

Zur damaligen Zeit waren dezentrale, selbstroutende Meshnetzwerke per WLAN selten. es gab Projekte wie das “roftop net” am MIT oder “Seattle Wireless”, die jedoch nicht wirklich unserer Idee eines flachhierarchischen Ansatzes entsprachen. allerdings beschäftigte man sich damals auch im nicht weit entfernten Berlin bei olsrexperiment.de mit der Idee von sozialen Fensterbrett-zu-Fensterbrett Netzwerken und den dafür nötigen technischen Mitteln. Dort wurden wir fündig und begannen aus der Berliner Firmware unsere eigene Leipziger Version zu stricken.

Als sich später aus olsrexperiment.de die freifunk.net Idee und ihre Community formierte, schloss sich die Leipziger Gruppe der Firmware, der Idee und ihren Grundsätzen (u.a. das “Pico Peering Agreement”) umgehend an.

Olsrd wurde also auch unser erster Routing Algo der Wahl, um die Idee eines Adhoc Mesh’ im urbanen Raum umzusetzen. Wir entschlossen uns damals bewusst die wichtige IP Vergabe in Form einer simplen Liste in einem offenen, pseudonymen Wiki zu regeln. Es war mitunter bei technischen Problemen zwar ärgerlich, denn einige eingetragene IPs waren nicht einmal mit einem Emailkontakt versehen. Allerdings wollten wir eine administrierte Freischaltung aus Gründen des unbedingt offenen Konzeptes vermeiden. Immerhin brachte es die Leipziger Community Mitte der 2000er Jahre mit dieser Methode auf legendäre mehrere hundert aktive Knoten.

Im Gegensatz zum Berliner freifunk Projekt, in dem es zum früheren Zeitpunkt für mobile Endgeräte nur möglich war am Netzwerk teilzunehmen, wenn diese auch ihrerseits olsrd laufen hatten, entschieden wir uns in Leipzig für eine NAT und DHCP Lösung, bei der Clients ohne eigenes OLSRouting am Knoten eine temporäre Lease bekamen und folglich zum Mesh genattet wurden. Strittiger Kernpunkt dieser Debatte war, dass die Zuweisung einer DHCP Lease einen hierarchischen Vorgang darstellte und wir technische und soziale Hierarchien eigentlich gänzlich vermeiden wollten.

Wir wollten, dass Menschen sich minimalinversiv, dezentralisiert und selbstbestimmt in ihrer Nachbarschaft vernetzen konnten und forderten auch jeden freifunk Knotenbetreiber darüber hinaus auf, eigene Dienste im freifunk Mesh anzubieten. Es wurden Plugins für olsrd geschrieben. Es wurden im Mesh Asterisk, Jabber, Blog, Streaming, File und sonstige Server eingerichtet. Es war die Zeit der freifunk Content Debatten, es war ein spannender Spielpatz, auch inhaltlich. Glücklicherweise konnten Knotenbetreiber, die über Gateways zu anderen Netzen verfügten, diese auch ins Mesh einbinden. So tröpfelte auch in den Opalgebieten des Leipziger Südens manchmal etwas Internet aus der Luft, weil nette Menschen nebenan ein Gateway geöffnet hatten. Schon damals war die Frage nach dem Öffnen des eigenen Internetanschlusses für das freifunk Mesh eine heikle Angelegenheit. Es gab auch damals Angst vor “Saugern”, der wir allerdings nicht mit technischen Filtern und Blockaden begegneten, sondern mit sozialen Mitteln, wie Aufklärung und Information (u.a. auch eine Splashpage). Denn im freifunk ist die Freiheit des einzelnen nur so groß wie die seines Nachbarn, es geht darum Ressourcen zu teilen. freifunk ist darum auch immer soziale Basisarbeit, die wir nicht durch technische Mittel erledigen können.

 

Zeitsprung: 2015

Als von der freifunk Community und vom Netzwerk unabhängige (auch namentlich unabhängige) Internet Service Provider (ISP) gegründet wurden, mit dem Ziel provisorisch und temporär juristische Fussangeln der Störerhaltung zu umgehen und den Internet Traffic über entfernte Gateways abzuleiten, ist es in einigen Teilen der bundesweiten freifunk Community offensichtlich zu gravierenden Missverständnissen über den grundsätzlichen Charakter eines “freien” freifunk Netzes gekommen.

Im Westen der Republik sehe ich, dass freifunk Vereine und ISP Konstrukte entstehen, die leider nicht den Bau freier Netzwerke fördern, sondern selbst offiziell als Anbieter von Internetzugängen agieren. Die Ideen des Teilens und der Allmende gehen damit verloren.

Es ist paradox, da die freifunk Idee nicht nur dem Namen nach für “freies funken” steht, sondern auch konzeptionell niemals für ein reguliertes, zentralisiertes Gratis-Hot-Spot-Netz mit integriertem Vereins- oder ISP-Betrieb stand. Das geht nicht gut zusammen und darüber muss in der freifunk Community dringend geredet werden.

Ich möchte darum alle Freifunkerinnen dazu auffordern miteinander zu sprechen, wie wir unsere Netze gestalten, ob wir freie, offene, unregulierte und flache (auch sozial flache) Strukturen bauen oder ob wir mit einer Servicementalität von kommunalen Internet Lieferanten zu Werke gehen. Freifunk kennt keine Kunden und sollte niemals mit dem Lieferversprechen eines Providers konzeptioniert und betrieben werden, denn neben der Idee des hierarchielosen und freien “people owned” Netzwerkes ist freifunk auch eine soziale Community idee, die so dezentral und führungslos funktioniert, wie der im Mesh benutzte algo. Und so wie die Nodes die Informationen über Routen und erreichbare Knoten austauschen, sollten die freifunkerinnen auch ihr Wissen miteinander teilen. Echtes freifunk ist darum auch nicht durch externe, einzelne Eingriffe abschaltbar.

Wir müssen uns klar sein, dass die ISP Lösung nur bei der Umgehung der Störerhaftungsfrage half und ohne die Störerhaftung der freien Funkidee sogar hinderlich werden kann. Sollte die Störerhaftung für private, offene WLANs fallen, so müssen umgehend alle juristischen und technischen ISPkonstrukte im freifunk beseitigt werden.

Ein ideales freifunk Mesh besteht aus autonomen, vom User selbstverwalteten Routern auf jedem einzelnen Fensterbrett einer Strasse und eines Kiezes; eine Meshwolke, die die Menschen lokal vernetzt – eine alternative offene Infrastruktur im urbanen Nachbarschaftsraum. Alle darüber hinaus von einzelnen angebotene Dienste und Gateways innerhalb dieses Mesh’ sind quasi Extras, die sich das offene freifunk Netz lediglich als Transportnetz zu nutze machen. Darum kann auch auf das schon erwähnte Pico Peering Agreement im freifunk an keiner Stelle verzichtet werden.

Wer jetzt die freifunk Idee und ihren Namen benutzt, um regulierte und zentralisierte Hot-Spot Wolken zu bauen oder lokale ISP-Instanzen zu gründen, der verschenkt fahrlässig zuvor mühsam erkämpften politischen und sozialen Raum, den die freifunk Community mit ihrer Idee immer schon definiert hatte. Lokale, selbstverwaltete und nicht-kommerzielle ISPs sind wichtig und wünschenswert. Allerdings haben sie bezüglich ihres Designs und ihrer Funktion nichts mehr mit der ursprünglichen freifunk Vision zu tun. freifunk kann per Definition niemals ISP sein.

Und auch per default eingeschaltete automatische Updatefunktionen in der Firmware, sowie hinterlegte Keys sind nicht mit der Idee einer freien, selbstbestimmten und dezentralen Netzwerkstruktur vereinbar. Die Hoheit über seinen Knoten liegt bei UserIn.

Lasst uns wieder unregulierte Netze bauen, freie freifunk Netze.

#freifunkbefreien

Sven Heinze, @kinolux

Freifunk-Broschüre “Freie Funknetze in der Praxis” von Medienanstalt Berlin-Brandenburg

Die Medienanstalt Berlin-Brandenburg (mabb) hat eine eine Broschüre “WLAN für alle – Freie Funknetze in der Praxis” veröffentlicht. Aus der Pressemitteilung: Aktuelle Publikation der mabb informiert umfassend über das Thema „Freifunk“.

Sie erläutert ausführlich, was sich hinter „Freifunk“ verbirgt und welche Chancen und Risiken mit diesem Netz verbunden sind. Mit der Publikation möchte die mabb die Freifunk-Community dabei unterstützen, die Bekanntheit von Freifunk in der Öffentlichkeit zu vergrößern. Noch kennen zu wenige Bürger und Institutionen die Möglichkeiten dieses Netzes. Und die, die es kennen, haben Bedenken und Vorbehalte es zu nutzen oder selbst anzubieten. Fragen wie „Ist das Freifunk-Netz sicher?“, „Mache ich mich strafbar wenn ich meinen Router für andere öffne?“ oder „Hafte ich für illegale Downloads anderer?“ werden immer wieder gestellt. Die Publikation der mabb greift diese Fragen auf und gibt praktische Erläuterungen und Anwendungshinweise für Nutzer und Anbieter.

Die Broschüre kann als als PDF heruntergeladen oder analog bestellt werden. Die Inhalte stehen unter einen freien Creative Commons-Lizenz.

 

Freifunk API – Spendenkampagnen und Unterstützer, Metacommunities

Die Freifunk API wird in kleinen Schritten immer weiter entwickelt. Manchmal sind es nur kleine Verbesserungen z.B. im Generator, hin und wieder kommen aber auch neue Felder hinzu.

Neue Features

Zentrales Thema der letzten Iteration war die Unterstützung der lokalen Community. Neben Spendenkampagnen kann man auch Informationen zu einem Förderverein eintragen.

Unterstützende Vereine

Um die Metacommunities besser darzustellen, gibt es unter “How to support you?” einen Eintrag für einen unterstützenden oder fördernden Verein. Neben Name und Adresse kann man Emailadresse und Homepage angeben sowie den Vorstand nennen. Die Felder sind alle optional.

Spenden

Immer mehr Communities setzen auf Spendenkampagnen von betterplace. Bis vor kurzem haben wir versucht, die Übersichtsseite über diese Kampagnen von Hand zu pflegen. Wegen der großen Anzahl wurde das immer schwieriger. Wir fassten den Entschluss, die Spendenkampagnen über die API einzusammeln. Im Moment wird nur betterplace als Plattform unterstützt, da niemand eine andere nutzt und uns auch keine bekannt ist, die Gleiches leistet wir betterplace. Um eure Kampagne über die API bekannt zu geben müsst ihr lediglich die ID der Kampagne angeben und die Plattform “betterplace” auswählen. Eure ID könnt ihr in der URL zu eurer Spendenseite bei betterplace finden. Es ist die Zahl nach “/projects/”, bei “https://www.betterplace.org/de/projects/12172-freifunk-net” z.B. die 12172.

Die Spendenübersicht hat nun ein eigenes WordPress-Plugin bekommen, dass die Daten aus der API einsammelt und in einer Tabelle darstellt. Informationen zu einigen Trägervereinen sind schon vorhanden, vom Rest erwarten wir noch einen kleinen Text.

Daneben kann natürlich auch ein Bankkonto angegeben werden, um direkt Spenden zu bekommen.

Falls ihr auch eine eigene Spendenkampagne starten wollt, aber keinen gemeinnützigen Verein als Träger habt, könnt ihr auch den Förderverein Freie Netzwerke e.V. kontaktieren.

Timeline

DelphiN aus Franken arbeitet gerade daran, die Timeline-Daten aus der API aufzubereiten. Am Ende sollen sie in einem Zeitstrahl dargestellt werden. Viele Communities haben hier erfreulicherweise schon Daten eingetragen. Wir freuen uns, wenn es noch mehr werden. Einige Einträge sind jedoch zu fein granuliert, als dass man sie sinnvoll in einem Zeitstrahl zeigen kann. Es ist nicht sinnvoll, das Aufstellen einzelner Router oder jedes Treffen in der Timeline zu dokumentieren. In dieser sollen sich Meilensteine (z.B. 100 Router, 1000 Clients gleichzeitig), wichtige Daten (Gründung, ggf. Wiedergründung) oder Ereignisse von großer Tragweite wiederfinden. Einige Vorschläge für Einträge:

  • Ereignisse
    •   Gründung
    •   Neugründung
    •   Vereinsgründung
    •   RIPE-Mitgliedschaft
    •   Event vermesht (Festivalname, Ort, Link zu Blog)
    •   Wichtige Kooperation geschlossen (Partnername, Link zu Blog)
    •   wichtiger Standort vermesht, z.B. Rathaus, Kirche, Schule, Fußgängerzone (Standortname, Link zu Blog)
  • Technik
    •   Knoten
      •     Erster Knoten online
      •     mehr als 100 Knoten online
      •     mehr als 500 Knoten online
      •     mehr als 1000 Knoten online
  •   Clients
      •     mehr als 100 Clients parallel
      •     mehr als 500 Clients parallel
      •     mehr als 1000 Clients parallel
    • Firmware
      •   Major Release mit Firmware Name, Version

Umgang mit Metcacommunities

In letzter Zeit haben wir API-Entwickler intensiv über den Umgang mit Metacommunities diskutiert. Ausgangspunkt war, dass zwei sich zwei Metacommunities zusätzlich in das Directory eingetragen haben und die Gesamtknotenzahlen neben den einzelnen Werten aus den Communities gemeldet haben. Das verfälscht natürlich das Ergebnis. In Zukunft soll mit Metacommunities so umgegangen werden:

  • Es gibt für Metacommunities keinen eigenen Eintrag im Directory
  • Fördervereine werden stattdessen in die neue Sektion für Vereine eingetragen
  • Das Feld Metacommunity bleibt erhalten und kann zur Gruppierung der API-Daten verwendet werden.
  • Der Collector wird erweitert, um neben der flachen Ausgabe aller Communities wie bisher auch eine nach Metacommunities gruppierte Datei zurückzugeben. 

Das Vorgehen hat mehrere Vorteile: Die API-Dateien und das Verzeichnis bleiben in einer einfachen Struktur erhalten. Alle Daten, um Gruppierungswünsche zu realisieren sind weiterhin vorhanden und können genutzt werden. Zur Erstellung von API-Dateien nutzt Freifunk Franken z.B. Templates, die dann um jeweile regionale Daten ergänzt werden.

Weitere Entwicklungen – Helfer gesucht

Im Umfeld der API sind einige Werkzeuge und Anforderungen entstanden, für deren Weiterentwicklung und Umsetzung wir Mitstreiter suchen. Hilfe ist immer herzlich willkommen. Meldet euch über das Kontaktformular, wählt “Frage zur API” und schreibt uns.

Collector

Der Collector ist ein kleines Python-Propgramm, dass momentan aus den API-Daten eine HTML-Tabelle, ein JSON für die Communitykarte und eine Konkatenation aller API-Dateien generiert. Durch die Erweiterung soll eine weitere Ausgabe hinzukommen, die die Daten in der folgenden Struktur als JSON-File zurückgibt:

  • Metacommunity1
    •   Community1 in Metacommunity1
    •   Community2 in Metacommunity1
  • Community3 (hat keine Metacommunity)
  • Metacommunty2
    •   Community4 in Metacommunity2
    •   Community5 in Metacommunity2
  • Community6

DeepaMehta – Freifunk Query Client

Im Rahmen des Google Summer of Code 2014 hatten wir mit der Arbeit an einem Query Client begonnen. Erst in der Mitte des Projekts lernten wir DeepaMehta kennen, eine Software zur semantischen Datenablage und zum Wissensmanagement. Erste Ergebnisse zum Import des Verzeichnisses und einiger API-Daten konnten wir schon erzielen. Eine erste Abfrage selektiert alle Communities nach einem Routingprotokoll, z.B. Batman Advanced oder OLSR. DeepaMehta erfordert Kenntnisse in Java und Maven.

Freifunk beim Google Summer of Code

Google nutzt für viele seiner Dienste OpenSource-Software. Mit dem Google Summer of Code möchte sich Google bei der OpenSource-Gemeinde bedanken und fördert Studenten für ein von Mai bis August laufendes Projekt mit 5500 US$ – in diesem Jahr über 1100 Studenten aus aller Welt.

Im Jahr 2014 nahm Freifunk wieder am Google Summer of Code teil. Freifunk integriert dabei als Dachorganisation weltweit Initiativen wie guifi.net, ninux.org, wlan slovenija und LibreMesh aus Argentinien. Wir bekamen in diesem Jahr 9 Slots für Projekte, die Studenten in Deutschland, Frankreich, Italien, Spanien und Slowenien bearbeiteten. Die Projekte beschäftigten sich u.a. mit der Freifunk-API, Netzwerkprotokollen und Software zum Communitymanagement. Im Freifunkblog können Details zu den Projekten nachgelesen werden.

Den Abschluss des diesjährigen Google Summer of Code bildete der Mentors Summit, zu dem jede Organisation zwei Mentoren entsenden darf. Zur Feier des 10-jährige Bestehens waren auch Teilnehmer aus den vergangegen Jahren eingeladen und der Summit wurde um einen Tag verlängert.

Freifunk fun in USA

Auf dem Programm stand auch ein Ausflug, wo wir das echte Amerika kennenlernten und gemeinsam mit Teilnehmern aus China und Vietnam Basketball trainierten.

Mehr als 600 Teilnehmer aus aller Welt trafen sich in San Jose, Kalifornien, und wir hatten die Chance uns über unsere Projekte auszutauschen, neue Kontakte zu knüpfen und nicht zuletzt den 10. Google Summer of Code zu feiern. Als Überraschungsgast zum Jubiläumsempfang war Linus Torvalds geladen. In einem Treffen hatten wir die Gelegenheit, mit ihm über Freifunk zu sprechen.

Ideen für Projekte im Jahr 2015 können schon jetzt im Wiki eingetragen werden. Falls ihr Kontakte zu Universitäten oder Fachhochschulen habt, sprecht mit Dozenten, Studenten oder Lehrstuhlinhabern, um Unterstützung für Projekte im Sommersemester 2015 zu bekommen.

Links

Projektideen http://wiki.freifunk.net/Ideas

Fotos zum Mentor Summit: https://www.flickr.com/search/?tags=gsoc14

Linus Torvalds and Dirk Hohndel meetup with Freifunk Community at Google Reunion

Freifunk attendees had the chance to discuss Community Networks with Linus Torvalds and Dirk Hohndel from Intel at the Google Mentor Summit. Linus said, it was impressive to see the growth of community networks around the world and it is exciting to see so many people working on Linux for embedded devices.

Linus Torvalds, Mario Behling, Federico Capoano, Freifunk, Google Summer of Code

Links sammeln und Termine teilen

Was ist das?

Die beiden Werkzeuge LinkSink und Calcifer sind nun einsatzbereit. Mit LinkSink können wir für Freifunk Links zu unseren Themen zusammentragen und daraus RSS-Feeds erstellen. Durch Kategorisierung und Hinzufügen von Tags können wir damit sehr flexibel RSS-Feeds zu bestimmten Themen bereitstellen und bei vorhandenen Mediendateien sogar diese einbinden. Calcifer kann man zum Verwalten von Terminen und Erstellung von ics-Dateien verwenden. Auch hier kann nach Tags und Orten gefiltert werden.

Für einige Anwendungen nutzen wir beide Werkzeuge schon aktiv:

Wie funktioniert das?

Auswahl und Filter

LinkSink Filter

Auf der Startseite sind zunächst alle Einträge zu sehen. Durc h einen Klick auf ein Tag eines Eintrags oder durch Nutzung der Filterleiste kann man diese Auswahl einschränken. In Calcifer kann derzeit entweder nach Tags oder nach Orten gefiltert werden. Filter in LinkSink können Kategorie, Jahr und ein Tag enthalten.

Link zum Feed

Fü r ein Filterergebnis steht dann ein Link zum RSS-Feed oder der ICS-Datei bereit. Die URL des Feeds bleibt konstant, so dass diese in anderen Anwendungen permanent eingesetzt werden kann. Mit jedem Aufruf wird der dahinterliegende Feed neu erzeugt und mit aktuellen Daten gefüllt. Calcifer erzeugt dabei nur in der Zukunft liegende Termine. LinkSink ordnet die Einträge absteigend nach Erscheinungsdatum.

Neue Links oder Termine kann man mit einem Klick auf Neuer Link bzw. Neuer Termin oben in der Navigationsleiste anlegen. Dann öffnet sich das entsprechende Formular. Sind alle Pflichtfelder richtig gefüllt, kann der neue Eintrag gespeichert werden.

Formular MediendateienMediendateien wie bei Podcasts können zu einem Linkeintrag hinzugefügt werden. Die notwendigen Felder für Länge und Typ stellt LinkSink beim Speichern fest und schreibt die Werte in die Datenbank. Die RSS-Feeds sind so aufgebaut, dass Podcastclients integrierte Audiodateien erkennen können und abspielen.

Calcifer kann auch wiederholende, regelmäßige Termine anlegen. Als Intervalle sind wöchentlich, 2-wöchentlich und monatlich auswählbar. Das Verwaltung wiederkehrender Termine erreicht man durch einen Klick auf den Link in der Navigationsleiste oben.

BookmarkletZur Erleichterung der Aufnahme neuer Links gibt es ein sogenanntes Bookmarklet. Das ist in der Navigationsleiste rechts oben zu finden. Um es zu nutzen, zieht man es in die Bookmarkleiste des eigenen Browsers. Auf Webseiten, die als man als Link speichern möchte, drückt man dann auf dieses Bookmark und wird zu einem vorausgefüllten Formular in LinkSink weitergeleitet. Das Bookmarklet erfordert ein aktiviertes Javascript im Browser, bei Erweiterungen wie Privacy Badger müssen Ausnahmen für rss.freifunk.net erstellt werden, damit Javascript von einer anderen Seite ausgeführt werden kann.

Vereinbarungen

Damit das Chaos überschaubar bleibt sind hier noch ein paar wenige Regeln: 

  • soll ein Link im Medienspiegel auftauchen muss das Tag Medienspiegel gesetzt sein. Wenn es eine Community betrifft ist es schön, wenn ein weiteres Tag mit dem Communitynamen dazukommt
  • Für eine schöne Darstellung im Medienspiegel sollte das Quellmedium auftauchen. Der Titel für einen Medienspiegeleintrag sollte so aussehen: <Quellmedium>: <Titel>
  • Termine in Calcifer, die communityübergreifend stattfinden (z.B. WCW oder der Congress) verseht ihr bitte mit dem Tag freifunk_common. Diese Termine erscheinen dann im gemeinsamen Kalender mit der Markierung, dass es sich um einen übergreifenden Termin handelt. Communityeigene Termine taggt ihr bitte nicht mit freifunk_common, sondern z.B. mit eurem Communitynamen. Den Feed dafür könnt ihr dann per Freifunk API bereitstellen, wodurch sie ebenfalls in den gemeinsamen Kalender kommen. Dann sind sie aber als Termine eurer Community markiert.

Nutzung

Jede Community darf die beiden Werkzeuge gern benutzen. Achtet bitte darauf, die Tags und Orte richtig zu setzen, damit es nicht zu Überschneidungen mit anderen Communities kommt. Versucht auch, doppelte Einträge zu vermeiden, fügt lieber euer Tag zu einem Eintrag hinzu, falls ihr ihn auch in eurem Filterergebnis haben wollt.

Falls euch das alles zu unübersichtlich wird könnt ihr auch eigene Instanzen installieren. Beide Werkzeuge sind quelloffen und werden in Github-Repositories gepflegt (LinkSink, Calcifer) und freuen sich über weitere Installation oder Mithilfe und Anregungen zur Weiterentwicklung.

GSoC: Work on Freifunk API Query Client will go on

This is the final blogpost for my GSoC project for the Freifunk-API Query Client.

Goals
 
We want a comfortable tool to query all the Freifunk API files as there are nearly 100 communities all over Germany providing their data. There are already several applications like our community map, a common calendar, our feed aggrator or the community podcast collector. But it’s still hard to find communities by properties like routing protocols or focus topics.
 
Challenges
 
When we began this project we only planned to query the generated JSON data for the community in a browser and additionally provide query results via a webservice. But then we talked to several people and we heard about DeepaMehta with features like connectors to OpenStreetmap. So we did something what you don’t do normally: We changed our project goals before the midterm evaluations.
 
DeepaMehta is not just another database product, it provides a different way to store and handle data. It uses a graph to store connections between items and allows to modex complex datatypes and associations between them. We had to change our mind and had to learn a new kind of thinking. The API data is constantly evolving and changing and there a lot of cross-references in the data e.g. links to various nodemaps. We think the switch to DeepaMehta is useful because we can query the graph and add new relations and data without problems.

 
It’s difficult to handle different spec versions if you want to query all API files, because some fields changed, other fields were added to the specs or got another meaning. In an ideal world all communities update their files as soon as possible. But we all know, it will never happen like that. As a workaround we first focused on less fields, available in all versions.
 
What we got
 
We’re able to import communities from the API directory as a base entity. We also tried some different ways to import and store the specs, but we need some improvements here. By using the summarized API file, the import of our payload can be done via the DeepaMehta REST API.

The switch to DeepaMehta brought a lot of complexity to the project and I’m personally not happy my results at this point because I had trouble to spend enough time for the project. Additionally some basic problems like dealing with changing schema and data import are not really solved well at this point. The data is in DeepaMehta and can be queries with the included client but it’s not in a state where it’s usable for the community.

Overall the GSoC was an interesting experience for me. Through I’ve failed to set aside enough time for the tasks. The timely overlap with university lectures does not make it easier. So I can only recommend to know beforehand that you’ll have enough time to accomplish your goals. But the support from the Freifunk community was always great and helpful! As the project is not a state that can be considered ‘ready’ I’m continuing working on it.
 
Future Plans

I definitly want to finish the work at least to point where it can be used by the wider Freifunk community.

The default DeepaMehta client isn’t designated to query a lot of fields like our API provides. Here we need a new web based client to provide users an interface to select fields and get a proper response.

Work will continue on integrating the API data and DeepaMehta.

Repository: https://github.com/freifunk/query.api.freifunk.net

Final Blog Post: Netengine

Hi everybody, this is going to be my last blog post as a participant of GSOC2014. I’m very sad about this, those have been very hard worked months but very formative.

I improved both my coding skills but above all I have earned a work methodology thanks to my mentor Federico, who said to me to be more reflexive and to be more precise in what I do.

I have learnt some aspect of versioning (Git) I ignored before and learned much more on Python than I did by myself.

This is the “change log” of the last time period of the program: we developed a new backend, the HTTP backend. It aims to retrieve informations from the web admin interface of AirOS devices, that’s why we called it HTTP.

We wrote documentation about all the project, describing all the things an user should do both to contribute or use Netengine, trying to be as much more clear and to make it simpler as we could.

Unfortunately this is my last year as a student, no PhD on my way (for now), so I will not be eligible at all for next editions coming.

Greetings and thanks: I would like to thank Ninux , the community network I’ve worked with. I’ve had the possibility of joining their meetings, to talk a lot with every member and to be supported every time I had some problem about what I was doing.
Obviously my mentor Federico Capoano, Mario Behling from Freifunk who supervised projects.

For further questions on the project please visit https://github.com/ninuxorg/netengine or email us at ninuxdev@ml.ninux.org or read the docs!