Freifunk Halle

Ich hab mich vorhin spontan entschieden über das Wochenende nach Berlin zum Firmware Hackathon zu fahren. Informationen gibt es hier: http://pad.freifunk.net/p/firmware-berlin.

Falls jemandem Fragen bezüglich Vernetzung, Webseite oder Firmware oder VPN einfallen, die auch mal in einem größeren Rahmen diskutiert werden sollten, kann mir diese hier gerne mitteilen.

Kombination der Mesh-Protokolle OLSR und B.A.T.M.A.N. und der Versuch die jeweiligen Vorteile der Protokolle zu nutzen. Erstellt durch 3dfxatwork...

Das war zwar nicht primär folge des Hackathon, sondern mehr so durch generelle Überlegungen nach dem Battlemesh und unserem Sommertreffen.

Dazu möchte ich gleich mal noch ein paar Worte zu schreiben:
Die bisherige Konfiguration sieht vor, dass 2 virtuelle WLANs aufgespannt werden, eines davon das OLSR-Mesh-Netz (halle.freifunk.net) und eines im AP Modus (Freifunk-Hotspot-X.Y). Auf dem AP bekommt man IP Adressen aus dem Bereich 6.X.Y.0/24 welche am Router genated werden.

Die Idee Batman auch in Halle zu verweden soll vor allem den Vorteil bringen, dass man sich im Netz bewegen kann und nicht immer eine neue IP Adresse zu beziehen, sonderen die Alte weiter benutzen zu können, wenn man durch Roaming an einem anderen AP eingebucht wird.
Dazu ist es erforderlich, dass der AP gleich heißt. Der Vorschlag ist einfach die verkürzte IP wegzulassen und es Freifunk-Hotspot zu nennen.
Dies hätte auch jetzt schon den Vorteil, dass man seinem Telefon nicht jedes mal ein neues WLAN-Netz beibringen muss, sondern wird an jedem AP automatisch eingebucht, nur bekommt man andere IPs.

Um möglichst auch abwärtskompatibel zu bleiben, soll Batman zu zusätzlich genutzt werden. OLSR funktioniert auf der IP-Schicht, Batman auf der Layer 2 / Ethernet schicht, daraus ergibt sich, alle per Batman gemeshten Knoten bilden eine große Netzwerkbrücke (in der Zeichnung durch den Switch-Kasten) Symbolisiert.

Die Idee ist Batman über halle.freifunk.net meshen zu lassen und damit es sich möglichst wenig mit OLSR überschneidet, dies mit einem VLAN auf dem WLAN-Netz zu tun. Im obigen Beispiel ist das VLAN 12. Weiterhin wird das bisher genatete AP Netz mit in diese Brücke gehangen. Dies bedeutet man bräuchte nur einen DHCP Server in dem Netz und könnte alle Clients versorgen.
Dies spricht aber gegen die Ausfallsicherheit, deshalb sollte man mehrere bzw. wie bisher auf jedem Knoten einen DHCP-Server laufen lassen. Konfiguriert wird dieser wie bisher durch die am OLSR-WLAN zugewiesene IP 104.62.X.Y.
Batman wird erst einmal ausdrücklich nicht über VPN gesprochen, zum einen soll es wohl nicht so gut mit vielen Knoten skalieren (Vortrag von den Chemnitzer Freifunkern zu den Chemitzer Linuxtagen 2014) und würde auch erst mal einen Vorteil bringen. Roaming kann nur funktionieren, wenn immer ein Netz vorhanden ist, ist das Netz kurzzeitig nicht in Reichweite, so wird sowieso eine neue IP bezogen und der Vorteil ist weg.

Das heißt für die Betrachtung der Vorteile und Probleme muss nur auf eine lokale Zusammenhangskomponente geachtet werden, also eine lokale Gruppe von Routern.

Wenn mehrere DHCP Server im Netz sind, bekommt meißt der den "Zuschlag" welcher am schnellsten antwortet, dies wird wahrscheinlich oft der sein, von dem AP, wo man sich angemeldet hat. Dies ist also kein Problem. Nutzt man nur einen, so kann man in der Gesamten Wolke nicht mehr arbeiten, da man auch nicht mehr mit noch vorhandenen Routern kommunizieren kann.

Man stelle sich eine Kaskade von Routern vor (unten im Bild), an dem einen ist das Kommunikationsziel zu finden, hier das Internet. Bucht man sich nun im am weitesten entfernten AP ein und bekommt von ihm eine Adresse und bewegt sich anschließend zum dem AP direkt am Ziel, so würde batman die Daten erst zu dem entfernen AP leiten dieser dann über OLSr wieder zu dem AP am Ziel. Dies würde das Netz unnötig belasten. Hierfür haben wir aber noch keine Lösung, außer es erst einmal zu hin zu nehmen.

Weil ich ja geschrieben habe, dass das Batman weniger vom Hackathon kommt, möchte ich auch zusammenfassen, was wir dort gemacht haben und was das für uns bringt.

Es standen viele Sachen auf der Liste abzuarbeitender Themen und geschafft wurde ein großes.
Nämlich die Vereinheitlichung des Firmwareerstellungsprozessen. Die Firmwares sollten in Repositories verwaltet werden, so dass auch jeder heran kommt (und nicht nur wie bei mir lokal auf meinem Rechner), dass auch jemand anderes etwas ändern kann und es transparenter wird.

Weiterhin haben wir einen Build-Server (auch CIS) aufgesetzt, welcher sich die registrierten Repositories nimmt und wenn Änderungen vorhanden sich diese herunterlädt und die Firmware oder den Imagebuilder daraus baut. Dies kann dann auch gleich mit Tests geprüft werden, siehe dazu den Punkt Firmware-Tests hier. Diese Tests müssten für alle Communities nur einmal geschrieben werden und könnten bei allen getestet werden, nur lokal Spezielle Konfigurationen oder Programme müssten extra getestet werden.
Um auch die hallesche Community davon profitieren zu lassen habe ich unsere Programme bei github hinterlegt und angefangen die Firmwarekonfiguration für Halle auch bei github zu hinterlegen und einen Build-Slave bei mir eingerichtet.

Wenn unsere Firmware dann automatisch mit gebaut wird, würde ich das hier nochmal kund tun.

Danke für die ausführlichen Infos.

In Kiel wird, soweit ich das richtig verstanden hab, IPV6 auf "B.A.T.M.A.N. Advanced" gefahren.
Irgendwo hab ich gelesen, dass das auch mit OLSR funktionieren soll.

Wäre das nicht Grundsätzlich eine Überlegung wert, um der oben benannten Problematik der IP-Adressvergabe und deren Nachteile beim Roaming mit IPV4 zu begegnen?

Ohne IPV6 im Detail verstanden zu haben. Könnte man sich nicht die ganzen Meta-Ebenen und VLANs sparen wenn man IPV6 für`s Mesh verwendet?

Grüße vom Alex...

Ich wäre erst mal dafür überhaupt batman auf unserer Struktur auszurollen und dann erst mit ipv6 rumzuspielen. Das größte Problem was ich sehe sind die Kisten mit nur 4 MB Flash, das alles da drauf zu bekommen ist nicht ganz so einfach.

3dfxatwork hat geschrieben: Ich wäre erst mal dafür überhaupt batman auf unserer Struktur auszurollen und dann erst mit ipv6 rumzuspielen.

Es kann ja nicht schaden die Dinge ganzheitlich zu betrachten, bevor man sich eine Menge Arbeit macht, evtl. das Netz ändert und anschließend feststellt, dass es anders vielleicht hätte besser sein können. Deine ausführlichen Erläuterungen lassen den Schluss zu, dass Du Dir um die großen Dinge eben auch Gedanken machst. Wohl kaum ein Wunder als Entwickler. Die skizzierten Gedanken aus dem ersten Post und den folgenden Erläuterungen sind ja recht komplex, sind aber einleuchtend und klingen gut.

Die Problematik bei der IP-Vergabe bleibt aber und ist zwar durch verstreute oder zentrale DHCP-Server lösbar, aber irgendwie eine Kompromiss-Lösung. Ist es nicht möglich irgendwie die Link-lokal-Fähigkeiten von IPV6 oder evtl. mobile-IPv6 (https://www.youtube.com/watch?v=N2kvPCwJkLU) im mesh unabhängig von olsr oder batman zu nutzen? Ich rede nicht von den Endgeräten, Handys, Laptops usw...

Vielleicht findest Du ja einen Denkfehler, den Du mir postwendend zurücksenden kannst.

3dfxatwork hat geschrieben: Das größte Problem was ich sehe sind die Kisten mit nur 4 MB Flash, das alles da drauf zu bekommen ist nicht ganz so einfach.

IPV6 würde wohl auch einiges mehr an Rechenleistung benötigen. Kann man die Router benutzerfreundlich aufrüsten (Flash-Speicher, CPU wohl kaum)? Also unter benutzerfreundlich versteh ich, dass man nicht SMD zu löten braucht.


Gruß Alex...

Ich würde damit trotzdem erst einmal warten. Warum:
1. Die IPv6 Pakete sind schon mit drin, nur bei olsr und im meshkit kann man das nocht nicht konfigurieren, das stellt soweit kein Problem dar.
2. Wir wollen eben nicht wieder IP-Adressen festlegen, das würde aber passieren, wenn wir das mit olsr machen würden ohne gründlich ein Konzept zu entwickeln.
3. Wenn wir wieder Adressen verwenden, die uns nicht offiziell zugewiesen wurden, dann passiert uns möglicherweise das gleiche wie mit den aktuellen 104er Adressen. Wenn man private Adressen, also die Analogie zu 10/8 nimmt, das sind nicht die Link-local-Adressen, muss man wieder irgendwo NATen, was bei IPv6 eigentlich nicht vorgesehen ist. Macht man eine 1:1 Übersetzung kann, kann man dahinterliegende Router identifizieren. Somit sollte man gleich offizielle Adressen nehmen und kann dann auch gleich öffentlich Dienste anbieten.
3a. Bei öffentlichen Adressen sollte man unterscheiden, ob man die regelmäßig wechselt (annonymität) und ob man statische Adressen zulässt. Ich würde beides nutzen wollen, damit man zum einen ohne weitere Vorkehrungen eine statische Adresse hat um Dienste anzubieten und eine dynamische zum täglichen surfen.
4. Das ist zur Zeit noch bei vielen eine Baustelle, wir müssten also alles selbst machen.
5. Die Adressen könnten wir aus Berlin bekommen, sollten dafür aber über den Verein auftreten.
6. IPv6 VPN nach Berlin fehlt.
7. Firewall-Anpassungen fehlen.
8. Batman benötigt Punkt 1. und 3. bis 7.
9. IPv6 ist unabhängig von IPv4.

Wir können also erstmal das ganze Batman machen, IPv6 würde dann darüber auch laufen, wenn die restlichen Bedingungen erfüllt sind.

Vielen Dank für die ausführliche Antwort.
Du bist detailliert auf meine Äußerungen eingegangen und ich hab das Gefühl, dass das Thema spannend bleiben wird.

Grüße vom Alex...