Kategoriearchive: Allgemein

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.

Vorratsdatenspeicherung – schon wieder?…

Am 16. Oktober 2015 hat die Deutsche Bundesregierung mal wieder ein sehr umstrittenes Gesetz zur Vorratsdatenspeicherung durchgewunken, welches hoffentlich in den nächsten Monaten vom Bundesverfassungsgericht wieder einkassiert wird.

Unabhängig davon gilt allerdings nun zuerst einmal, dass solche Gesetze soweit möglich eingehalten werden müssen. Für Internet Service Provider bedeutet das eine Umsetzungsfrist von 18 Monaten.

Wir Freifunker sind nach aktueller Gesetzeslage und dank Klarstellung durch das Bundesverfassungsgericht von der Vorratsdatenspeicherungspflicht meiner Meinung nach nicht betroffen, da – wenn überhaupt – nur zu “Teilnehmern” diese Daten gespeichert werden müssen. Per Definition im TKG sind Teilnehmer aber nur “jede natürliche oder juristische Person, die mit einem Anbieter von öffentlich zugänglichen Telekommunikationsdiensten einen Vertrag über die Erbringung derartiger Dienste geschlossen hat;“. Da weder die WLAN-Routerbetreiber noch die Serverbetreiber/Unterstützer einen Vertrag mit den “Endnutzern” abgeschlossen hat, sondern die Netzzugangsbereitstellung nur eine Gefälligkeit ist, müssten wir mit der Vorratsdatenspeicherung nichts zu tun haben. Dies gilt allerdings nur solange das Picopeering Agreement eingehalten wird (-> Gefälligkeit).

Innerhalb der nächsten 18 Monate werden sich sicherlich viele Anwälte mit dem Thema befassen und detaillierte Stellungnahmen und Analysen veröffentlichen. Wir als Community sollten auf jeden Fall jegliche Möglichkeiten ausschöpfen um möglichst eine langfristige Abschaffung der Vorratsdatenspeicherung aus diversen Gründen zu erreichen. Siehe dazu auch http://freifunkstattangst.de.

Als nächstes steht leider auch noch immer die Neuregelung der WLAN-Störerhaftung an… (Hier droht aktuelle eine deutliche Verschlimmbesserung des Gesetzes, welches laut Politik “die Verbreitung von offenem WLAN unterstützen” soll – mit dem jetzigen Gesetzesentwurf würde genau das Gegenteil passieren).

Firmwareupdate 0.7.3 / Neuer Supernode: Salem

Wir haben soeben die neue Firmwareversion 0.7.3 zum Autoupdate freigegeben. Damit geht unser neuester Supernode, Salem, in den Produktivbetrieb über.

Geräte mit aktiviertem Autoupdater sollten wie gewohnt binnen weniger Tagen automatisch aktuallisieren.

Beim Aufbau des neuesten Supernodes haben wir auch Ansible-Definitionen ausgearbeitet, mit denen jetzt bei Bedarf automatisiert weitere Supernodes installiert werden können. Diese finden sich zur freien Verwendung in unserem Github-ansible-Repository.

Firmwareupdate 0.7.2

Wir haben soeben die neue Firmwareversion 0.7.2 zum Autoupdate freigegeben.

Neuerungen der Firmware:

  • Update auf Gluon 2015.1.2
    • Mehr unterstützte Geräte
    • Explizite Angabe aller unterstützten Ubiquiti-Geräten
    • Verschiedene Bugfixes
    • Weitere Details: siehe Gluon-Releasenotes von 2015.1.2
  • offizielle Unterstützung der Router Archer C5 v1 und Archer C7 v2 von TP-Link

Geräte mit aktiviertem Autoupdater sollten wie gewohnt binnen weniger Tagen automatisch aktuallisieren.

Freifunk für Flüchtlinge

Freifunk Trier​ würde gerne die Leute in den Aufnahmeeinrichtung für Asylbegehrende mit Internet versorgen und sucht dafür Leute, die ihren Internetanschluss zur Verfügung stellen würden (ca. <10Mbit Bandbreite). Wir würden die Technik stellen und haben auch Sponsoren, die uns dabei unterstützen. Die letzte Meile wird über Richtfunk gehen, das heißt ihr müsst auf Sicht zu den Aufnahmeeinrichtungen wohnen.

Das ganze ist legal und soll dabei helfen sich hier in Deutschland zu orientieren und Kontakt mit Verwandten zu halten. Bei Interesse schreibt uns einfach direkt an, informiert euch auf trier.freifunk.net oder kommt beim maschinendeck.org Treffen Mittwochs vorbei.

Um die Störerhaftung oder ähnliches brauchen sich die Inhaber der Internetanschlüsse dank Providerstatus und VPN-Tunnelung keine Sorgen zu machen.

 

Ziel ist die Versorgung der Standorte in der Dasbachstraße (Trier), der Luxemburger Straße (Trier), Bitburg und in Hermeskeil.

Statistiken am Rande

Wir hatten im Juli 1,7 TB Upstream-Traffic und 1,86 TB Mesh-Traffic auf den Supernodes.

20150805_2200_globalGraph_365d

Der Peak Clients lag bei 138, der Peak online Routers bei 74. Unser Netzwerk zeigt ein gesundes Wachstum.

20150805_2200_Firmwareversionen

4/5 der Router laufen auf aktuellster Firmwareversion.

20150805_2200_mesh

Die beiden größten zusammenhängenden Mesh-Wolken bestehen aus jeweis 6 Routern.

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

Pi and More

Am 20.06.2015 war die Pi and More an der Universität Trier. Freifunk Trier war mit 9 Routern und einem Infostand vertreten. Es gab viel interessantes zu sehen und viele interessierte Menschen, denen wir Freifunk erklären konnten.

20150620-piandmore-2000

Das Netz funktionierte sehr gut und verzeichnete zwischenzeitlich 75 Clients.

Neu: Meshviewer

meshviewer-tufa02
Seit dem 29.05.2015 haben wir den Meshviewer (externer Link) als alternative zur klassischen ffmap-d3 (externer Link) installiert. Meshviewer zeichnet sich dadurch aus auch auf der Kartendarstellung verbundene Clients darzustellen und ist damit besonders dazu geeignet auf Veranstaltungen an einem Infostand den aktuellen Status des Netzwerks darzustellen.

Der Meshviewer wird, wie auch die klassische ffmap-d3 minütlich aktualisiert, die externe Version stündlich.

Firmwareupdate 0.7.1

Am 18.07.2015 haben wir die neue Firmwareversion 0.7.1 zum Autoupdate freigegeben.

Neuerungen der Firmware:

  • Update von Gluon v2014.4 nach Gluon gluon-v2015.1.1-4-gda16254
    • Mehr unterstützte Geräte
    • Configmode auch in Englisch
    • mehr Einstellungsmöglichkeiten im Configmode (Mesh-on-LAN, reduktion der WLAN-Sendeleistung, auf Wunsch Abschaltung der VPN-Verschlüsselung zur Erhöhung des Durchsatzes, etc.)
    • verbesserte Sicherheit
    • viele Bugfixes zur Steigerung der Stabilität
    • Schnellerer VPN-Verbindungsaufbau durch fastd-Update von v16 auf v17.2
    • Weitere Neuerungen: siehe Gluon-Releasenotes von 2015.1 und 2015.1.1
  • Reduktion auf 1 VPN-Link pro Router
    Wir verwenden nur noch eine VPN-Verbindung pro Router, statt 2, und haben damit die Grundlast jedes Routers halbiert.
  • Eigenentwicklung: Integration einer abgespeckten Statusseite
    Die bisherige Stautsseite mit Live-Signalstärkeanzeigen belastete die Router stark. Da wir hin und wieder Probleme damit hatten, dass irgend jemand die Seite stundenlang offen ließ und damit die Performance des betreffenden Routers massiv beeinträchtigt wurde, haben wir eine abgespeckte Version der Statusseite entwickelt, die keine nennenswerte Last auf den Routern erzeugt. Außerdem zeigen wird, wenn im gluon-config-mode-supernode Munin eingeschaltet wurde, eine kleine Auswahl der Graphen des Routers an.
  • Integration unserer Eigenentwicklung gluon-fastd-tunneling-mtu-workaround
    Die “MTU” gibt die maximale Paketgröße an, die über eine Verbindung übertragen werden kann. Unser VPN-Tunnel zur Verbindung vom Uplink-Router zum Supernode braucht eine gewisse mindest-MTU um problemlos arbeiten zu können. Wenn die MTU des Anschlusses kleiner ist als diese mindest-MTU gibt es MTU-Probleme, die zum Beispiel dafür sorgen können, dass es zu merkwürdigen Verbindungsproblemen kommt. Dieses Skript versucht vollautomatisch MTU-Probleme zu erkennen und versucht diese mit verschiedenen Mitteln automatisch zu beheben: Sollte ein Uplink mit MTU-Problemen erkannt werden wird versucht auf IPv6 only umzuschalten, da gerade neue Dualstack-Light-Anschlüsse häufiger Probleme mit einer zu niedrigen MTU auf IPv4 haben. Sollte das nicht funktionieren wird versucht auf IPv4 only umzuschalten, da mansche Anschlüsse natives IPv4 und IPv6 über Tunnel und somit MTU-Probleme auf IPv6 haben. Sollte dieser Modus auch fehlschlagen wird wieder auf normalen Dualstackmodus zurückgewechselt, falls das Problem nur temporär auftritt. Diese Modus-Umschaltung betrifft nur die Verbindung zwischen Supernodes und Freifunk-Routern, nicht aber darüber angeschlossene Geräte. Im Freifunknetz Trier ist immer richtiges Internet sowohl mit IPv4 als auch IPv6 verfügbar.
  • configmode-supernodes[1]Integration unserer Eigenentwicklung gluon-config-mode-supernode
    Die Supernodes bieten verschiedene Dienste an, an denen manchmal Routerbesitzer Anpassungen vornehmen möchten. Das ist jetzt für 2 Dienste sehr einfach möglich:

    • ipv6-Firewall: Standardmäßig verbieten Supernodes direkte Verbindungen zwischen den Freifunk-Routern und dem Internet. Sollte der Routerbesitzer direkte Verbindungen aus dem Internet zu seinem Router wünschen, zum Beispiel für Fernadministration via SSH, können direkte Verbindungen zum Router nun über den Configmode freigeschaltet werden. Verbindungen von und zu Clients und sämtliche Verbindungen innerhalb des Freifunknetzes sind unabhängig von dieser Funktion immer möglich
    • Munin: Via Munin können vollautomatisch verschiedene Statistikdaten der Router erfasst werden. Diese Funktion kann auf Wunsch über den Experten-Modus des Configmode aktiviert oder deaktiviert werden.