Community

Vorstellung eines Freifunk Advisory Councils für die Communities

Information vom Förderverein freie Netzwerke e.V.

Liebe Freifunker_Innen,

wie im November des letzten Jahres angekündigt (siehe http://lists.freifunk.net/pipermail/wlantalk-freifunk.net/2014-November/000391.html), haben wir uns gemeinsam mit Euch Gedanken zur Gründung eines "Freifunk Advisory Councils" gemacht.

Das zu gründende Freifunk Advisory Council (AC) soll dem Förderverein freie Netzwerke e.V. zukünftig bei Entscheidungen zur Seite stehen.

Jede Community kann bis zum 14.05.2015 einen Vorschlag für ein Mitglied an die Mailingliste council-candidaten@freifunk.net melden (ACHTUNG: Alle Eingänge sind über eine öffentliche Mailingliste einsehbar). Zum Besetzungschlüssel des Advisory Councils und Verfahrensweisen haben wir unten alles aufgelistet.

Das Council wird vorerst auf eine Zeit von 12 Monaten gewählt, in denen auch die weiteren Details zur Zusammenarbeit geklärt werden. Vor allem die möglichst kurzen Fristen zur Beantwortung von Anfragen und Abstimmungspunkten durch die Mitglieder_Innen.

Weitere Details finden sich unten.

Rückfragen bitte ins Pad unter https://pad.freifunk.net/p/faq_advisory_council eintragen, wir versuchen Sie so schnell zu bearbeiten.

Ziel ist es, das Council spätestens im Rahmen des anstehenden WCWs initial zu besetzen.

Viele Grüße, schönes Wochenende,
Euer Vorstand des Fördervereins freie Netzwerke e.V. und die Mitwirkenden

P.S.: Dieser Text ging auch an die Kontaktadressen aller Freifunk Communities in Deutschland.

Funktionsweise und Aufgaben des Freifunk Advisory Councils (AC)

Aufgaben

  • Das AC entscheidet in Streitfragen bei der Vergabe von freifunk.net Subdomains oder API Einträgen
  • Beratung und Hilfe zur Beilegung von Streitigkeiten in bzw. zwischen Freifunk Gruppen

Zusammenstellung

Zur Einreichung von Vorschlägen wird benötigt:

  • (Vollständiger) Name
  • Bundesland
  • Community (in API eingetragene Stand 17. April 2015)
  • Email/Kontaktadresse

Sollten die Einreichungen eines Bundeslandes zahlenmäßig die Anzahl der zu entsendenden Repräsentanten übersteigen, organisieren die Communities des Bundeslandes eine Wahl. Bis dahin bleibt die Position
unbesetzt.

Die Besetzung ist angelehnt an die föderale Struktur der Bundesrepublik Deutschland: 21 Mitglieder

  • Baden-Württemberg 2
  • Bayern 2
  • Berlin 1
  • Brandenburg 1
  • Bremen 1
  • Hamburg 1
  • Hessen 2
  • Mecklenburg-Vorpommern 1
  • Niedersachsen 2
  • Nordrhein-Westfalen 2
  • Rheinland-Pfalz 1
  • Saarland 1
  • Sachsen 1
  • Sachsen-Anhalt 1
  • Schleswig-Holstein 1
  • Thüringen 1

Organisiation

Organisiert und kommuniziert wird über eine Mailingliste, die der Förderverein freie Netzwerke e.V. zur Verfügung stellt. Für Anhörungen oder Diskussion wird ein mumble empfohlen.

Anfragen

Jede_r darf Anfragen an das AC per E-Mail richten.

Abstimmungen im AC über Domain und API Fragen

  • Abstimmungsfragen werden nach Darlegung des Sachverhaltes vom AC als Ja/Nein Fragen formuliert.
  • Entscheide werden mit einfacher Mehrheit beschlossen.
  • Keine Antwort gilt als NEIN.
  • Entscheidungen werden an die Beteiligten des Streitfalles gesendet.
  • Ablehnende Entscheidungen bedürfen einer Begründung.

Treffen

  • das AC trifft sich mindestens einmal im Jahr in Persona
  • der Termin und Tagesordung wird innerhalb des AC abgestimmt
  • in Härtefällen kann der Förderverein freie Netzwerke e.V. einen Reisekostenzuschuss bewilligen

Aufnahme neuer Mitglieder, Ausscheiden, Ausschluss, Vertretung

  • Nicht besetzte Positionen sind Enthaltungen.
  • Beim Ausscheiden von Mitgliedern kann nachbesetzt werden, siehe Zusammenstellung.
  • Der Verteilungsschlüssel muss beibehalten werden.
  • Das AC kann Personen mit Zweidrittelmehrheit ausschließen
  • Pro Mitglied kann zusätzlich ein Vertreter bestimmt werden, der bei Verhinderung des Mitglieds einspringt oder bei Ausscheiden des Mitglieds bis zur Nach- oder Neubesetzung dessen Aufgaben übernimmt.

Reporting

Das AC verfasst am Ende des Jahres einen zusammenfassenden Bericht, über die Zahl und Art der Anfragen und veröffentlicht diese unter blog.freifunk.net.

Erstes Treffen mit den Netzpolitikerinnen von #r2g

Am Dienstag, dem 14.4. trafen sich die Thüringer Freifunker im Bytespeicher in Erfurt. Zu Gast waren die Netzpolitikerinnen (kein Binnen-I notwendig) der Linken und der Grünen, MdL Katharina König (Die Linke) und Madeleine Henfling (Bündnis 90/Die Grünen) sowie die Referentin der Parlamentarischen Geschäftsführung der Grünen im Landtag, Sandra Reda. Die Freifunker kamen von den Communities aus Jena, Weimar und Erfurt.

Ziel unseres Treffens war das gegenseitige Kennenlernen und zu erörtern, wie aus dem Freistaat Thüringen ein Freifunkstaat werden kann und wo es Möglichkeiten seitens der Landesregierung gibt, uns zu unterstützen. Nach einer Vorstellungsrunde haben wir unseren Gästen in einer kurzen Präsentation Freifunk und den aktuellen Stand in Thüringen vorgestellt:

Zentraler Punkt war natürlich der Koalitionsvertrag, in dem steht

Die Koalition unterstützt bürgerschaftliches Engagement im Bereich des Netzzugangs. Freifunkinitiativen in Thüringen sollen stärker gefördert und beraten werden. Ebenso werden die Kommunen bei Einrichtung öffentlicher WLAN-Netze unterstützt. Zur Herstellung von Rechtssicherheit setzt sich die Koalition auf Bundesebene für die Abschaffung der Störerhaftung für die privaten und kommunalen Anbieter freier Netzzugänge ein, wobei das Auferlegen von Datensammlungspflichten vermieden werden muss. Die Koalition wird ein Modellprojekt zum „Kommunalen WLAN“ und „WLAN im ÖPNV“ einrichten.

Im Moment ist es leider noch so, dass nicht feststeht, welches Ministerium definitiv für uns zuständig sein wird. In den nächsten Wochen soll sich das aber klären. Wir stehen an der Stelle gern zur Verfügung, den Verantwortlichen Freifunk vorzustellen und die Idee näher zu bringen.

Bei der Frage nach der Art der Förderung waren wir uns einig, dass eine rein finanzielle Förderung zu wenig ist. Zugang zu landeseigenen Gebäuden, verbunden mit der Übernahme von Strom- und Installationskosten sind an dieser Stelle viel wertvoller. Als weiterer wichtiger Punkt wurde gesehen, unsere Idee weiter im Land zu verbreiten und uns hierbei zu unterstützen. Daneben freuen wir uns auch sehr gern über politische Statements, die uns in unserem Kampf gegen Störerhaftung und Vorratsdatenspeicherung (aka Höchstspeicherfrist) und für Netzneutralität unterstützen.

Als weiteres wichtiges Anliegen sehen wir die Versorgung von Flüchtlingsunterkünften mit Internetzugang an. Das Internet als Grundversorgung und öffentliche Daseinsfürsorge muss selbstverständlich werden.

Unser Treffen war sehr angenehm und wir hoffen, dass das der Auftakt für eine fruchtbare weitere Zusammenarbeit ist. Es wären tolle Voraussetzungen, um Freifunk in Thüringen weiter auszubauen und neue Communities in anderen Städten und Gemeinden ins Leben zu rufen. Im Juni wird es das nächste Treffen geben. Bis dahin hat man sich hoffentlich die Frage der Zuständigkeit geklärt.

freifunk.net endorses the Battle of the Mesh v8

Battlemesh v8 poster

The "Wireless Battle of the Mesh" is an event that aims to bring together people from across the globe to test the performance of different routing protocols for ad-hoc networks, like Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s.

Many developers and community networkers will join the event to hack, test, discuss, explain and learn.

If you are interested in dynamic routing protocols or wireless community networks you can't miss this event!

The battlemesh is free of charge and open for all, every year we strive to keep participation costs low by negotiating deals for accommodation and food.

This year the event will take place from 3rd to 9th August 2015 in Maribor, Slovenia and will be hosted by Wlan Slovenia.

freifunk.net endorses and supports the Battle of the Mesh v8 because it's a great opportunity to meet all the developers and community network activists at one place. Our communities take benefits directly from results of the battle. The battlemesh gives us help and inspiration for further development of our firmwares and all the communities.

freifunk.net will support the event by:

  • help to promote the event
  • bring members of the community to the event
  • give talks about advancement of our community in certain aspects
  • provide hardware for the routing protocol testing
  • collect donations and will donate some money to the organizers

Many other communities endorse and support the Wireless Battle of The Mesh v8, an up to date list of the endorsers of the Battlemesh v8 can be found at the main Battlemesh website.

If you are interested in coming join the event's Mailing List to stay up to date with the latest news.

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.

Syndicate content