Kategoriearchive: Technik

Neue Gluon-Firmware 2016.2.7 — bitte testen

Allgemein Firmware Netzinfrastruktur Technik Keine Kommentare

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.

300 Knoten – Zeit für Statistiken

Allgemein Netzinfrastruktur Technik 1 Kommentar

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.

Layer 2-Anycast-Routing mit BATMAN

Allgemein Netzinfrastruktur Technik 5 Kommentare

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.

Firmwareupdate 0.7.3 / Neuer Supernode: Salem

Allgemein Firmware Netzinfrastruktur Technik 2 Kommentare

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.

Neu: Meshviewer

Allgemein Netzinfrastruktur Technik Keine Kommentare

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

Allgemein Firmware Netzinfrastruktur Technik Keine Kommentare

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.

Aktuelle Änderungen im Netz

Netzinfrastruktur Technik Keine Kommentare

In den letzten Tagen haben wir erfolgreich einen Wechsel der Internetanbindungs-Infrastruktur von VPN03 auf ICVPN>>Freifunk-Berlin durchgeführt. Dies bringt zukünftig eine deutliche Verbesserung der Kapazität und Ausfallsicherheit mit sich.

Leider war dieser Wechsel nur mit einer Änderung des IPv6-Präfixes (Internetadresse der Router) möglich – was in den letzten 3 Tagen zu ein paar Problemen bezüglich Meshing und Freifunkrouter-Überlastungen geführt hat. Wir bitten dies zu entschuldigen. Seit heute morgen 05:00 Uhr sollten diese Probleme durch den abgeschlossenen Wechsel (und Firmwareupdate 0.6.6) behoben sein.

Ein weiterer Vorteil des durchgeführten Wechsels ist nun die Verfügbarkeit von IPv6 (mit globalen Adressen) im gesamten Trier Freifunknetz. Außerdem können andere Freifunknetze, das dn42, Raumzeitlabor-Netz und viele weitere Netze im Intercity-Verbund aus unserem Freifunknetz direkt erreicht werden.

Das Treffen am 18.02.15

Allgemein Firmware Netzinfrastruktur Organisation Technik 1 Kommentar

Heute (18.02.15) hat sich Freifunk Trier wieder im Rahmen des wöchentlichen Treffens des Vereins Maschinendeck getroffen. Anfangs haben wir wieder das Meshing der Router getestet sowie Erfahrungen im Testbetrieb der Freifunk-Router seit letzter Woche ausgetauscht. Bislang läuft die Software sehr stabil und zuverlässig, wird allerdings noch optimiert und um neue Funktionen wie z.B. optional die Bereitstellung eines privaten WLAN neben Freifunk und Mesh in einem Gerät erweitert.

FreifunkTreffen1

 

Neben einer Runde Dart haben wir über die weitere Architektur des Netzes diskutiert und besprochen, an welchen Orten in der Stadt Freifunk-Router aufgestellt werden könnten. Die ersten Vereine und Institutionen wurden bereits angeschrieben, Antworten stehen jedoch noch aus. Eine erste Visualisierung des Trierer Freifunk-Netzes wurde eingerichtet und eine Sammelbestellung von zehn Freifunk-Routern (TP-Link WR841N à 14,86€ inkl. Versand) aufgegeben.

ff_mapNeu
Um Informationen über die entstehende Trierer Freifunk-Community auf der freifunk.net Website bereitzustellen, wurde ein Eintrag in der Freifunk-API erstellt.

Insgesamt war deutlich zu sehen, wie schnell die Freifunk-Community Trier und der Maschinendeck e.V. wachsen – die Besucherzahlen steigen rasant!

Viele Hürden – viel Unterstützung

Netzinfrastruktur Technik Keine Kommentare

Nach dem Treffen im Maschinendeck.org wollten wir natürlich heute alle Planungen in die Tat umsetzen.

Ranlvor vom Maschinendeck stellt uns eine Virtuelle Maschine als Supernode kostenfrei zur Verfügung. Vielen Dank nochmals dafür!

Analog zum Freifunkwikibelanglose Codezeilen-Artikel “Freifunk_Hamburg/Gateway” begannen wir die notwendige Software zu installieren und versuchten passende Konfigurationen zurecht zu basteln. Es stellte sich beispielsweise die Frage, ob BATMAN-adv aus dem im Wikiartikel angegebenen Repository überhaupt die zu userer Routerfirmware passende Version ist. Eine Anfrage an FFHamburg brachte schnelle Unterstützung.

Einige Stunden später fanden wir allerdings heraus, dass der Wiki-Artikel nicht mehr auf dem aktuellen Stand ist und einiges gänzlich anders umgesetzt werden müsste. Außerdem erfuhren wir nun, dass es sogar halb-automatische Konfigurationssoftware (sogenannte Puppet-Scripte) für die Einrichtung der Supernodes gibt.

Als nächstes steht nun das Anpassen der Puppet-Scripte an unsere Community auf dem Plan. Dies ermöglicht später auch das einfache und schnelle hinzufügen weiterer Supernodes (Gatewayserver) und somit eine einfache Erweiterung unseres Netzwerkes. Der Arbeitsstand des Puppet-Scriptes kann hier gefunden werden.