Schlagwort-Archive: radv-filterd

Neue Firmware Version 2017.1.4+mwu4 (testing)

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

da der radv-filterd in 2017.1.4+mwu2 immer noch Probleme gemacht und beim (Neu)starten eines Knotens nicht immer zuverlässig gestartet ist haben wir versucht das Problem mit einem Patch, der in 2017.1.4+mw3 eingeflossen ist, zu beheben. Dieser Patch hat auch seinen Zweck erfüllt hätte aber aufgrund der unsauberen Implementierung zu Probleme führen können weshalb wir uns gegen das Ausrollen der Version entschieden haben. Glücklicherweise hat kurz darauf einer der Gluon Entwickler den gesamten radv-filterd einem Code Review unterzogen und mehrere Fehler gefunden und behoben. Diese Version haben wir für v2017.1.4 zurückportiert und darauf basierend den Release 2017.1.4+mwu4 gebaut.

Zusätzlich zu oben genannter Änderung haben wir uns dazu entschieden einen Patch [1] aus der aktuellen Entwicklungsversion von Gluon zu übernehmen der die Bridge Loop Avoidance (BLA) funktionsfähig macht. In der Vergangenheit kam es immer wieder vor, dass Knotenbetreiber versehentlich (das hoffen wir jedenfalls) die LAN-Ports von zwei oder mehr Knoten verbunden haben ohne diese für Mesh-on-LAN zu konfigurieren. Dadurch wird eine Netzwerkschleife erzeugt, die den gleichen Traffic immer und immer wieder durch das Freifunk-Netz schickt bis dieses unbenutzbar wird. Mit dem Patch können zwei Knoten, die auf diese Weise verbunden sind, das Problem erkennen und die Schleife unterbrechen.

[1] https://github.com/freifunk-gluon/gluon/commit/f799518194307857510c0ce3ee9df582081353ee

MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2017.1.4+mwu4

Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/testing
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/testing
Link zur Firmware Rheingau: https://firmware.freifunk-rtk.de/rheingau/testing
Link zur Firmware Taunus: https://firmware.freifunk-rtk.de/taunus/testing

Fehlerberichte bitte über die Maschinenraum Liste.

Wir gehen davon aus, dass nun alle Probleme behoben sind und wir die Firmware, sofern ihr oder wir keine neuen feststellen, binnen der nächsten zwei Wochen zum nächsten Stable Release be­nen­nen können.

Happy Testing wünscht,
das Firmware-Team

Neue Firmware Version 2017.1.4+mwu2 (testing)

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

da der radv-filterd in 2017.1.4+mwu1 nicht richtig funktioniert haben wir uns entschieden einen weiteren Testing Release zu veröffentlichen. Das Programm ist dafür zuständig auf den Knoten Filterregeln anzulegen die verhindern, dass Clients Router Advertisements von alle Gateways erhalten [1]. Bisher hat das Programm die Ausgaben von batctl/debugfs nach den benötigten Werten durchsucht. Dieses Vorgehen ist leider sehr fehleranfällig da sich das Ausgabeformat bei den letzten BATMAN Advanced immer wieder geändert hat. Seit einigen Versionen ist es aber auch möglich die Werte über Netlink abzufragen. Genau dies haben wir jetzt in radv-filterd implementiert.

[1] https://blog.freifunk-mainz.de/2017/01/08/ipv6-optimierungen-im-freifunk-mainz-wiesbaden-und-umgebung-mwu/

MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2017.1.4+mwu2

Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/testing
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/testing
Link zur Firmware Rheingau: https://firmware.freifunk-rtk.de/rheingau/testing
Link zur Firmware Taunus: https://firmware.freifunk-rtk.de/taunus/testing

Fehlerberichte bitte über die Maschinenraum Liste.

Der Stable Release ist weiterhin für Anfang nächsten Jahres geplant.

Happy Testing wünscht,
das Firmware-Team

IPv6-Optimierungen im Freifunk Mainz, Wiesbaden und Umgebung (MWU)

Seit der Aktivierung öffentlicher IPv6 Adressen für alle Clients hatten wir aufgrund unser Netzstruktur einen ungünstigen Datenfluss bei ein- und ausgehenden IPv6-Verbindungen. Weil Datenpakete nicht den kürzesten Weg durch unser Netz genommen haben, sondern intern weiter verteilt werden mussten, hat dies zu einem unnötigen Bandbreitenverbrauch geführt. Das Verhalten hat uns einiges an Kopfzerbrechen bereitet, letztendlich hat unser Admin-Team aber eine Lösung gefunden, die in den letzten Wochen stückweise aktiviert und verprobt wurde.

Das Problem

Unsere Freifunk MWU-Netze (Mainz, Wiesbaden und Umgebung) bestehen aus vielen kleinen Teilnetzen die mittels B.A.T.M.A.N. Advanced zu einem großen virtuellen Layer 2 Netzwerk zusammengeschaltet werden. Innerhalb dieser Netze kann jedes Gerät direkt mit allen anderen kommunizieren. In jedem dieser Netze gibt es vier Gateways die im wesentlichen drei Aufgaben haben. 1) Sie sind die VPN Gegenstelle für alle Knoten, 2) Default Gateway für alle Clients und 3) kümmern sich und die Ausleitung des Internetverkehrs über den Freifunk Rheinland. Aufgrund dieser virtuellen Netztopologie wissen die Endgeräte nichts über die wirkliche Struktur des Netzes.

Dies war solange kein Problem, wie wir extern nur über IPv4 kommuniziert haben, da jedes Gateway eine eindeutige Adresse hatte und sämtlicher Internetverkehr der Clients mit diesen geNATet wurde. Hierdurch konnte der Freifunk Rheinland immer eindeutig zuordnen über welches Gateway die Verbindung initiert wurde und hat die Daten immer auf dem für uns kürzesten Weg übertragen.

Mit IPv6 ist es aber nicht mehr nötig NAT einzusetzen (Nein, NAT ist kein Sicherheitsfeature!) da 2^128 Adressen verfügbar sind, dass sind ca. 600 Billiarden Adressen pro mm². Ohne NAT wird die Adresse bei ausgehendem Datenverkehr nicht mehr durch die des Gateways ersetzt wodurch die Systeme des Freifunk Rheinland nicht mehr zuordnen können über welches Gateway die Anfrage gesendet wurden und senden die Daten an das erstbeste. Unsere Gateways müssen sich dann darum kümmern die Daten intern an das Gateway weiterzuleiten über welches die Daten angefragt wurden. Da diese, wie bereits erwähnt, bei verschiedenen Hostern stehen entsteht ein unnötige Belastung der verfügbaren Bandbreite.

Die Lösung

Wir haben verschiedene Ansätze diskutiert und kamen am Ende nur zu einer Lösung. Wir müssen unsere Netze (/48) in kleinere Subnetze (/56) segmentieren. Gesagt, getan. Seit ein paar Tagen besitzt jedes Gateway sein eigenes Subnetz. Leider ist dies nur die halbe Lösung da es nur für eingehende Daten hilft. Durch unser Layer 2 Netz erhält jeder Client die Router Advertisements (im folgenden kurz RA genannt) von allen Gateways und trägt sich deshalb auch alle vier als Default Gateway ein. Da der Client nicht weiß, an welches Gateway der Knoten per VPN verbunden ist, kann er keine qualifizierte Entscheidung treffen, welches Gateway für ihn das Nächste ist.

Glücklicherweise haben sich bereits andere kluge Menschen darüber die Köpfe zerbrochen und ein Programm namens gluon-radv-filterd entwickelt. Dieses Programm muss auf den Knoten laufen und ist seit der Version 2016.2.2+mwu1 in unser Firmware enthalten. Die Funktion ist relativ einfach zu verstehen: Alles was das Programm tut, ist, sich jedes eingehende RA Paket anzuschauen und zu prüfen welche Verbindungsqualität (TQ) B.A.T.M.A.N Advanced zu der Gegenstelle hat die dieses gesendet hat. Anschließend wird eine Filterregel erstellt die alle RAs verwirft die nicht von der Gegenstelle mit der besten TQ kommen. Da die TQ mit jedem Hop sinkt können wir sicher sein, dass das RA Paket mit der besten TQ vom nächstgelegen Gateway kommt.

Bei Fragen oder Feedback wendet euch bitte an die Maschinenraum-Liste.