Die „Hoods“ kommen

Wir wollen weiter wachsen und müssen uns der Tatsache stellen, dass größere Netze auch einen größeren Traffic-Overhead bedeuten. Das würde unweigerlich dazu führen, dass wir bald mit jedem hinzukommenden Router ein wenig langsamer werden, weil immer größere Datenmengen im Netz nur noch dazu gebraucht werden, um die Infrastruktur zu managen und somit unseren Clients nicht mehr zur Verfügung stehen.

Diesem Szenario wollen wir rechtzeitig mit neuen Verwaltungsstrukturen in unserem Netz entgegenwirken. Ein probates Mittel in vielen anderen Communities sind die Einführung von „Hoods“.
Hoods oder auch „Netz-Segmente“ sind strukturierte, voneinander abgegegrenzte Bereiche einer gemeinsamen Freifunk-Community. Diese mindern den Traffic-Overhead des Gesamtnetzes enorm.

Wir haben uns in den letzten Monaten viele Gedanken über mögliche Strukturen in unserem Netz gemacht und sind zu dem Ergebnis gekommen:

  • wir werden Netzsegemente bei uns ebenfalls einführen (Endausbau: 16 Stück)
  • wir wollen, dass jedes Gateway auch jedes Segment betreuen kann
  • wir wollen vermeiden für jedes Segment eine eigene Gluon-Version zu erstellen

Unsere Gateways sind in den vergangenen Monaten mehrfach umstrukturiert worden. Zum einen haben wir in Berlin 2 Gateways, die unseren IPv4-Traffic jetzt direkt ausleiten ins Internet. Danach wurden alle anderen Gateways degradiert und arbeiten den Gateways in Berlin nur noch zu, haben weder einen eigenen Uplink ins Internet, keinen DHCP-/RA-Service, kein DNS, noch eine eigene tinc- und BGP-Session. In einem weiteren Schritt haben wir auf allen GWs für jedes geplante Segment eine Bridge, eine Fastd-Instanz und je einem BATMAN-Interface aufgerüstet. Die Verbindung der GWs untereinander erfolgt mit jeweils 5 Fastd-Tunneln. Diese Zahl wird in Zukunft mit jedem weitern Netzsegment steigen.

Derzeit sind noch alle Knoten im Netzsegment „00“ unterwegs. Mit dem neuen Firmwareupdate „0.9.0+tackin“ bekommt jeder Router eine neue Knfiguration, die ihm überhaupt erst ermöglicht, an den neuen Netzsegmenten teilzunehmen. Sobald wir die Vorbereitungen zum „Go“ für die Segmente abgeschlossen haben, werden wir auf unseren GWs steuern, welcher Router sich in welches Netzsegment integrieren wird (und wirklich NUR dort). Eure Router werden das automatisch erledigen, es gibt nichts was ihr tun müsst … sofern euer Router das besagte Update auch installiert hat.

Alle Router, die ältere Software nutzen und einen Uplink haben, werden danach dann keine Verbindung mehr zu unserem GW aufbauen können. … Sorry!

Ein Risiko bleibt

Die Segmente/Hoods haben allerdings immer ein Risiko. Es ist nicht ausgeschlossen, dass ein User (absichtlich oder unbeabsichtigt) zwei Router betreibt, die untereinander verbunden sind, aber in zwei unterschiedlichen Netzsegementen eingebucht sind. Dieses „bridging“ bringt die Netze durcheinander und führt zu massenhaftem unsinnigem Traffic. Dem könnten wir begegnen, indem wir für jedes Segment auch eine eigene Gluon-Version erzeugen, die dann verhindern soll, dass die beiden Problem-Router sich überhaupt untereinander verbinden können.
Ich vertraue jedoch erst einmal darauf, dass dieses Problem bei uns nicht oder nur sehr sehr selten auftritt, sodass der Aufwand einer eigenen Gluon-Version in keinem Verhältnis dazu stehen würde. Wenn sich zeigt, dass Maßnahmen nötig sind, werden die Router, die an dem Bridging beteiligt waren, dauerhaft von unseren GWs ausgesperrt. Im Extremfall, werden wir auch eigene Gluonversionen einführen.

Wir werden die Segmente anhand der Hostnamen festlegen. Dabei nutzen wir die PLZ um GEO-Regionen festzulegen indem ein Segment arbeitet. Daher war in der Vergangenheit die Angabe der PLZ erwünscht. Das bedeutet: ihr dürft NIE zwei Router mit unterschiedlichen PLZ gemeinsam nebeneinander mit uplink betreiben – auch und besonders nicht testweise.

  • Solltet ihr für einen anderen Ort einen Router vorbereiten, dann darf dieser Router zwar testweise gerne im WLAN-Mesh teilnehmen, Ihr dürft aber keinen Uplink zu unserem GW mit diesem Router zulassen.
  • Sollte sich der Aufstellort ändern, brauchen wir die Info damit wir ggfl. das Netzsegment dieses Routers anpassen
  • Schickt uns den Key mit dem Hinweis, ab wann wir den eintragen sollen, damit ihr in Ruhe testen könnt, aber kein Bridging passieren kann

Neue Gluon-Firmware 2016.2.7 — bitte testen

Letzte Woche habe ich neue Software compiliert. Ihr findet diese, wie immer, auf  Github Experimental. Die Software trägt meine Versionskennung „0.9.0+tackin“, basiert auf Gluon 2016.2.7 und wurde auf einigen Routern bereits erfolgreich als Upgrade geflasht. Daher würde ich euch gerne bitten, diese ebenfalls bei euch sowohl als Factory als auch als Upgrades auf diverser Hardware zu testen. Sofern im weiteren Verlauf der Tests keine Probleme auftreten, ist geplant diese Version als neues Stable-Update auszurollen. Etwaige Fehler-/Problemberichte bitte an uns weitergeben.
Alle vorab mit dieser Version geflashten Router befinden sich weiterhin im Stable-Branch und werden sich also auch in Zukunft automatisch mit kommenden Updates versorgen. (Ihr hängt also nicht in einem „Testbranch“ fest.)
Wie bereits im Mai angekündigt, ist dieses Vorbereitungsupdate hier auf die erste LEDE-Version unbedingt nötig. Wir können also LEDE erst ausrollen, wenn „0.9.0+tackin“ überall erfolgreich läuft. Daher bitte ich eure Router zügig mit dieser Version upzudaten oder zumindest ein Autoupgrade an euren Routern zu ermöglichen.
„Unter der Haube“ gibt es bei diesem Gluon-Update auch einige weitere zwingende Neuerungen. Dazu schreibe ich aber einen eigenen Artikel.

Fazit: Wer nicht updatet wird in einigen Wochen leider kein Freifunk bei uns mehr genießen können.

Unterstüzung neuerer Hardware

Immer mal wieder werden wir gefragt, wann es denn auch eine Firmware für diesen oder jenen neuen Router mit dieser oder jener Hardware-Version geben wird. Die Frage stellt sich natürlich immer dann, wenn der Freifunker in unserer Firmware-Liste nicht fündig wird. Und dass euer Router sich NIEMALS mit Images für frühere Hardwareversionen erfolgreich flashen lassen wird, sollte jedem klar sein.

Falls ihr die Firmware in einer anderen Community schon findet, dann bedeutet es,
entweder
wir hinken etwas hinterher und müssen unbedingt nochmal den Firmware-Backautomaten anwerfen um die aktuellen Images zu bauen.
Hier lohnt dann der Blick auf evtl. vorhandene andere Branches (z.B. „tackin“ oder „experimental“). Diese Builds sind jünger und werden in der Zukunft u.U. sogar unsere neue „stable“-Release.

oder
Die Firmware ist als BROKEN markiert. Dann funktioniert diese Firmware nicht zuverlässig, hat Macken und Einschränkungen oder schrottet gelegentlich auch mal den Router. Solche Firmware bauen wir eigentlich nicht für den Download.

LEDE und/oder ibss/11s haben übrigens bis dato, soweit mir bekannt, keinen Einfluß auf verfügbaren Firmware-Images.

Falls ihr die Firmware auch in anderen Communities nicht findet, dann haben wir die ganz sicher auch nicht. Es erübrigt sich dann auch jedes Nachfragen ob und wann die verfügbar sein wird. Wir wissen es schlicht und ergreifend in aller Regel nicht.

Freifunk ist keine „Firma“ mit eigener „Entwicklungsabteilung“.
Jede Firmware entsteht, weil sich jemand mit viel Sachverstand erbarmt, sich Tage oder Wochen hinsetzt und die Soft- und Hardware des neuen Routers inspiziert und versucht Gluon/openwrt darauf ans laufen zu bringen. Selbst wenn wir wissen, es arbeitet gerade jemand an einer Firmware für Gerät X, heißt das noch lange nicht, dass jemals auch eine Firmware wirklich verfügbar sein wird. Manchmal sind die Hürden der Hardware einfach zu hoch weil elementare Treiber fehlen oder nicht sauber arbeiten. Dann wird es auch nach Monaten halt keine fertige Firmware für Gerät X geben. Diese Geräte sind dann evtl mit Gluon als BROKEN-Image betreibbar. Der Support dafür ist aber einfach unmöglich und Totalverlust beim Flashen sehr gut möglich.

Beispiel aus der Praxis:
Professionelle Entwicklung eines Opensource-Treibers für neue WIFI-Chipsätze in aktuellen Routern dauert viele Monate und kostet gerne mal 50.000 Euro. Das kann Freifunk nicht bezahlen, weil Freifunk keine entprechenden Einnahmen hat. Falls also jemand der Community jetzt finanziell unter die Arme greifen möchte um diese elementare Entwicklungsarbeit zu professionalisieren, dem können wir sofort passende Ansprechpartner vermitteln.

Wer tiefer einsteigen will: Hier findet Ihr alle Targets / Router für die es prinzipiel eine Firmware gibt.

Neue Firmware ausgerollt

Mit unserem letzten Stable-Firmware 0.8.4 gab es kaum Probleme. Lediglich einige CPE-Hardware und neuere Routermodelle machten zwischen durch mal neue Experimentals notwendig. Daher gab es auch wenig Grund für ein generelles Update.

In den letzten Monaten kamen nun aber auch bei unserer Infrastruktur einige Veränderungen zusammen, die in einer neuen Firmware jetzt berücksichtigt werden mussten. Nachdem alle Änderungen an unseren Gateways erledigt waren, haben wir uns also entschlossen eine neue Stable-Release zu bauen. Dieses Release basiert auf „Gluon 2016.2.5“ und wird wohl das letzte Gluon sein, welches auf OpenWRT basiert.
Am 27.4.2017 fiel der Startschuss für den Roll-Out unsere neue Stable-Firmware „0.8.6“. Stand heute haben sich über 400 unserer Freifunkrouter per Autoupdate problemlos mit dieser neuen Software versorgt.

Unser Fahrplan:
Das nächste Gluon-Release (und damit auch unsere nächste Stable-Router-Firmware) wird noch ein Bugfix- und Vorbereitungsupdate auf LEDE sein und muss unbedingt installiert werden (oder euer Knoten wird sich beim Übergang zu 2017.1 aufhängen). Danach erfolgt mit 2017.1 unsere erste LEDE-basierte-Firmware und die wird auch unser Mesh massiv verändern. Unser Ziel ist ein sicherer Migrationspfad des Funkstandards von IBSS auf 802.11s in unserem Netz zu realisieren. Ein Paralellbetrieb von IBSS und 802.11s führt leider zu massiven Problemen und ist daher auch für eine Übergangszeit nicht machbar.
Schon jetzt sei also hier angekündigt, dass mit diesem Wechsel zu 802.11s dann alle Router mit älteren Firmwareständen und ohne aktiviertem Autoupdate von unserm Mesh-Netz dann plötzlich ausgesperrt sein werden. Wir empfehlen daher euere Router (und die eurer Nachbarn) auf aktuelle Firmware zu prüfen und die Autoupdate-Funktion aktiviert zu lassen.

Freifunkertreffen in Sirzenich

Wir waren gestern mal wieder auf eine Pizza und ein paar Bier zu Gast bei Christoph im Dorftreff Sirzenich. Der Dorftreff ist, wie unsere Freifunker-Community, ein tolles Beispiel für modernes ehrenamtliches Engagement zum Wohl der Gemeinden. Infos: Dorfgemeinschaft Sirzenich  Die Renovierung und das neue Ambiente des alten Gemäuer sind wirklich beeindruckend.

Der Dorfgemeinschaftsverein verwaltet den Dorftreff mit dem Ziel einen Beitrag für ein lebendiges Dorf mit Zukunft zu leisten. Konzerte, Flohmärkte, Kaffee-Nachmittage, Senioren-Treffen und eine Location auch für private Feiern und Fest, bringen Alt-Sirzenicher und Neubürger hier jede Woche zusammen. Jeden Freitag trifft man sich so z.B. auf dem Vorplatz beim Bääker zum Bier und frisch gebackener Pizza. Der Andrang ist in der Regel so groß, dass man auf die Pizza schon mal 2 Bier lang warten muss.

Gemeinsam mit Christoph vom Dorfgemeinschaftsverein haben wir rund um den Dorftreff im letzten Jahr Freifunk nach Sirzenich gebracht. Grund genug also mal wieder dort auch nach dem Rechten zu sehen.

Christoph wir danken dir natürlich sehr für deine herzliche Einladung zu euch in den Dorftreff und für die spitzenmäßige Beköstigung.

 

300 Knoten – Zeit für Statistiken

Letzten Dienstag Abend haben wir die 300 aktiven Router geknackt!
globalgraph_365d

Da unsere aktuelle stable Firmware die WR841N V10 und V11 noch nicht unterstützt haben wir zur Zeit eine etwas chaotische Softwarebestückung. Das wird sich vermutlich in den nächsten Wochen bessern.
firmware-statistik

Auch auf der Meshkarte kann man unseren Fortschritt klar erkennen:
mesh1

Unser größtes zusammenhängendes Mesh hat 31 Knoten, unser zweitgrößtes 23.
mesh2

Alle Informationen dieses Blogposts wurden aus unserer internen ffmap-d3 (externer Link) entnommen.

Freifunk-Stammtisch im Textorium Trier!

Am ersten Montag des Monats Juni, dem 06.06.2016, trafen sich wieder die Freifunker*innen zu ihrem monatlichen Stammtisch. Als Treffpunkt diente dieses Mal die Gastronomie in der Tuchfabrik Trier – das Textorium. Bei dem Treffen ging es u. a. um den weiteren Ausbau von Freifunk in Flüchtlingsunterkünften rund um Trier.

20160606_202038

Darüber hinaus wurde ein neues Gerät (TP-LINK TL-WA860RE) im Textorium getestet. Durch eine zusätzliche temporäre Installation in der Räumlichkeit des Textorium konnte die Qualität des Freifunknetzes und somit auch der Internetzugang für die Gäste merklich gesteigert werden.

IMG_1379

 

Der nächste Stammtisch findet am 4. Juli um 18:30 Uhr wieder im Dorftreff Sirzenich, Hauptstr. 20 in 54311 Trierweiler statt. Gäste sind herzlich willkommen! Mehr Informationen gibt es in unserer Mailinngliste

Freifunk-Stammtisch in Sirzenich!

Am Montag, dem 02. Mai, wird der erste Freifunk-Stammtisch in Trierweiler stattfinden. Das Treffen beginnt um 19 Uhr. Wir treffen uns im Dorftreff Sirzenich, Hauptstr. 20 in 54311 Trierweiler. Gäste sind herzlich willkommen!

Die Vision von Freifunk ist die Verbreitung freier Netzwerke, die Demokratisierung der Kommunikationsmedien und die Förderung lokaler Sozialstrukturen. Durch die Vernetzung ganzer Ortsteile wollen wir der digitalen Spaltung entgegenwirken und freie unabhängige Netzwerkstrukturen in Bürgerhand aufbauen.
Der Zugang zu Informationen und Wissen soll frei sein! Wir wollen, dass jeder an Informationen kommt, ohne dass jemand diese zensiert oder beschränkt! Jeder Datenverkehr im Freifunknetz ist gleichberechtigt! Viele Freifunk-Knotenbetrieber stellen auch einen Teil Ihrer Internetverbindung für die Gemeinschaft zur Verfügung. Hierdurch können deren Mitmenschen freies, drahtloses Internet, ohne Registrierung, zeitliche Begrenzung und sonstige Limitierungen nutzen. Wird die verschlüsselte Verbindung zu den Freifunkservern genutzt, kann der Freifunk-Anbieter auch nicht im Rahmen der Störerhaftung haftbar gemacht werden.

Freifunk gibt es nicht nur im Großraum Trier, sondern ist eine deutschlandweite Bewegung für freie digitale Infrastruktur. Hierbei werden handelsübliche WLAN-Router entsprechend modifiziert, sodass der Zugang zum Freifunk-Netz ohne Passwort möglich ist. Diese Freifunk-Router werden dann von Privatleuten und Gewerbetreibenden, z. B. Gastronomen, an deren Internetverbindung angeschlossen. Dabei kann der Anbieter selbst bestimmen, wie viel Bandbreite er dem Freifunknetz zur Verfügung stellt. Dies wirkt sich dann darauf aus, wie schnell das Internet für Freifunk-Nutzer letztendlich sein wird.

Das Freifunknetz ist dabei vom Netz des Anbieters getrennt, so dass das private Netz des Anbieters geschützt ist. Abgesehen vom Stromverbrauch entstehen für den Anbieter keine weiteren monatlichen Kosten.

Freifunk Trier wird vom ehrenamtlichen Engagement der Mitglieder und von Spenden getragen. Ein kompatibler Router kostet 15 bis 60 €, je nach benötigter Leistung.

Falls du mehr Informationen benötigst, wir beraten dich gerne beim Stammtisch oder jeden Mittwoch im Maschinendeck. Wir freuen uns auf deinen Besuch!

Flüchtlingsunterkunft in Bekond funkt frei

Unbenannt

Die Router werden bereits rege genutzt

Die Flüchtlingsunterkunft im ehemaligen Hotel „St. Thomas“ am Brunnenhof in Bekond (Verbandsgemeinde Schweich) ist seit dem 19. Januar 2016 mit Freifunk versorgt. Die etwa 50 dort untergebrachten Bewohnerinnen und Bewohner, die überwiegend aus Syrien stammen, haben nun kostenfrei und ohne Beschränkungen Zugang zum Internet. Ein Internetzugang erleichtert den Flüchtlingen unter anderem das Erlernen der deutschen Sprache und hilft dabei, den Kontakt zu Angehörigen in der Heimat oder in anderen Asylunterkünften aufrecht zu erhalten. Ermöglicht wurde dies auch durch eine Spende des Routerherstellers TP-Link, der den Freifunk-Communitys zahlreiche Router für die Versorgung von Asylunterkünften zur Verfügung gestellt hat.

Direkt nach dem Aufstellen der beiden Router haben die Geflüchteten das freie WLAN entdeckt. Etwa 20 Geräte haben sich sofort mit dem Netz verbunden, unter anderem, weil die Flüchtlinge schon zuvor (z. B. in Trier) Freifunk genutzt haben. Ein direkter Anwohner der Unterkunft teilt seinen Internetanschluss und ermöglicht so die Versorgung der Asylunterkunft. Wir suchen jedoch noch andere Anwohnerinnen und Anwohner, die bereit sind, ihren Internetanschluss zu teilen und so einen besseren und ausfallsichereren Internetzugang für die Geflüchteten zu ermöglichen.

Layer 2-Anycast-Routing mit BATMAN

Bisher wurde Traffic von Clientgeräten ins Internet via Unicast geroutet. Dazu musste das Clientgerät explizit angeben, über welchen Gateway der Traffic ins Internet geleitet werden sollte. Wenn das Clientgerät nicht den besten Gateway gewählt hat führte dieses Verhalten eventuell zu unnötigem Traffic zwischen unseren Gateways.

Wir haben am 13./14. Oktober Layer 2-Anycast-Routing ausgerollt. Hierbei gibt der Client nur noch an, dass der Traffic an irgendeinen Gateway geleitet werden soll und das Netz leitet den Traffic automatisch zum nächstgelegenen Gateway.

Die Idee selbst wurde bereits im BATMAN-Wiki beschrieben: Man aktiviert die Bridge Loop Avoidance batctl bl 1 und vergibt eine Anycast-MAC-Adresse und bindet an diese dann die Anycast IP-Adressen. Wir verwenden dazu, wie im Wiki vorgeschlagen, MAC-VLAN-Interfaces. Siehe dazu auch unsere Konfiguration auf Github.

Bei den MAC-VLAN-Interfaces ergibt sich ein Problem: Standardmäßig antwortet ein Linux-Host auf ARP-Anfragen an alle seine IP-Adressen mit der MAC-Adresse des Interfaces, an dem die Anfrage eingeht. Wenn also ein Client versucht die MAC-Adresse zur Anycast-IP-Adresse herauszufinden antwortet der Gateway mit seiner Unicast-MAC-Adresse, da das Unicast-Interface das Paket als erstes gesehen hat. Dieses Verhalten kann man umstellen auf „antworte nur dann, wenn du an diesen Client auch über dieses Interface routen würdest“. Das geht mit sysctl -w net.ipv4.conf.all.arp_filter=1. Siehe dazu auch die entsprechende Kernel-Dokumentation.

Als nächstes haben wir dann das Problem, dass der Gateway genau dann, wenn die Anycast-IP-Adresse im Spiel ist, das Anycast-Interface benutzen soll und sonst das normale Interface. Dieses Problem lässt sich mit Source-Routing lösen:

if ! grep -q anycast /etc/iproute2/rt_tables; then
	echo 11 anycast >> /etc/iproute2/rt_tables
fi

#the anycast-mesh-ip is routed via the anycast-mac
ip rule add from 10.172.0.10/32 table anycast
ip route add table anycast 10.172.0.0/16 dev fftr-gw-anycast

Jetzt haben wir eine Anycast-IP-Adresse, die man anpingen kann und die man für Services wie DNS benutzen kann. Darüber routen kann man aber noch nicht, denn der rp_filter verwirft Pakete, auf dem Anycast-Interface, da der Kernel zurückkommende Pakete nicht über das Anycast-Interface routen würde, da sie nicht die Anycast-IP-Adresse als Quelle haben. Daher schalten wir den rp_filter einfach ab: sysctl -w net.ipv4.conf.fftr-gw-anycast.rp_filter=0; sysctl -w net.ipv4.conf.br-fftr.rp_filter=0.

Nach diesen Änderungen hat man eine funktionsfähige Layer 2-Anycast-Adresse. Nun kann man den DHCP-Server anpassen, damit diese Adresse für IPv4-Traffic verwendet wird und das Programm, welches die IPv6-RAs sendet an das Anycast-Interface binden damit für IPv6-Traffic die link-local Anycast-Adresse verwendet wird. Auch seine iptables sollte man nicht vergessen anzupassen.

Unsere kompletten Konfigurationsänderungen lassen sich auf Github betrachten.

Update 09.11.2015:

Aufgrund von Meldungen verschiedener merkwürdiger Probleme durch unsere User und fehlender Zeit für weitere Analyse haben wir Anycast zur Zeit wieder abgeschaltet und fahren wieder Unicast.