Version vom 27. November 2017, 18:53 Uhr

Erklärung

Mit dem KeyXchangeV2 werden den Routern nicht nur wie bisher VPN Endpunkte genannt, sondern die komplette Routerkonfiguration. Damit wird dem Router seine Hood mitgeteilt und er kann sich entsprechend konfigurieren. Eine solche Konfigurationsdatei sieht etwa so aus:

[1]

Da KeyXchangeV2 zum alten System nicht kompatibel ist, werden auch einige Systeme aktualisiert:

Batman Compat v15
11s statt IBSS Mesh

Grundsätzlich kann man sich das V2-Netz als komplett neues Netz vorstellen, mit neuen Hood-Grenzlinien, die auf der Monitoringkarte rechts oben mit einem Klick auf den Papierstapel und einen Haken bei HoodV2 eingeblendet werden können. Router mit alter und neuer Konfiguration meshen nicht untereinander. Eine Kommunikation zwischen alten und neuen Hoods ist jedoch auf IPv4 Basis möglich. Auch die Aufteilung der Hoods wird neu aufgesetzt. Je mehr Router in die neuen Hoods umziehen, desto mehr Hoods müssen dort erstellt werden. Je weniger Router die Hoods im alten System haben, umso häufiger kann man sie auflösen bzw. zusammenfassen, bis es am Ende nur noch sehr wenige oder gar keine Router in der letzten Default-Hood geben wird.

Vorteile

Verschiedene Hoods können nicht mehr miteinander meshen
Jede Hood hat eine eigene SSID (nach RFCXXXX ist es richtig, dass jedes L2-Netz eine eigene SSID hat).
Router können hoodübergreifend erreicht und konfiguriert werden (über nun routbare fd43:*** Adressen).
Auf den Gateways wird nicht nicht mehr der Key des Routers geprüft. Somit kann jede Hood auch manuell ohne KeyXchange betreten werden!
Das Monitoring bekommt die Daten dezentral von den Gateways und nicht mehr zentral von der NetmonVM.
Neue Hoods sind deutlich leichter anzulegen.
- NetmonVM muss nicht mehr angepasst werden.
- Monitoring muss nicht mehr angepasst werden, Hoods entstehen dort von alleine sobald Router sich mit einer neuen Hood melden.
Allgemein wurde das System so entwickelt, das es eine Vorstufe zum dezentralen KeyXchange wird. Dieses System ist weiterhin noch nicht 100% dezentral, wir nähern uns diesem Ziel aber an. Wer jetzt schon dezentral sein möchte, kann dies problemlos realisieren, wie div. Hoods (StPaul, Marterlach, Stmarkus, Unterfürberg, Hardhöhe, Neunhof, FabLabnbg, etc.) beweisen.

Informationen

Inbetriebnahme Uplinkrouter

Nach dem Flashen wird der Router wie bisher über den blauen Port mit dem Internet verbunden. Nach Neustart sollte er eine SSID mit den Namen 'trainstation.freifunk' ausstrahlen (kann u.U. etwas länger dauern! 5 Minuten oder länger sind beim ersten Bootvorgang möglich). Über diese SSID kann man sich mit dem Router verbinden, den Router wie bisher ansprechen und konfigurieren. In dieser Hood ist kein Zugang zum Internet möglich. Einige Freifunk-Seiten sind dennoch erreichbar:

Monitoring
Freifunk Franken Wiki
OSM Karte damit im WebUI des Routers auch die Karte geladen wird.

Um die Hood zu ändern, müssen nach Login auf dem Router die korrekten Geokoordinaten gesetzt werden, damit er sich nach Neustart mit einer gültigen Hood verbindet. Der Knoten/Router sollte nun eine SSID in der Art: STADT.freifunk(.net) ausstrahlen. Darüber ist normaler Zugang zum Freifunknetz und dem Internet möglich.

Inbetriebnahme Meshrouter

Per WLAN

Jeder fertig konfigurierte Router strahlt eine versteckte SSID config.franken.freifunk.net aus. In dieser SSID wird nur ein Konfigurationfile für Meshrouter angeboten.

Ein Meshrouter, der am WAN Port kein Internet hat, sucht selbstständig nach diesem versteckten Netz und holt sich dort die Konfiguration. Anschließend ist er als Meshrouter in der Hood des Partnerrouters aktiv. Dies funktioniert problemlos auch mit dezentralen Hoods, sofern sie entsprechend aktualisiert sind (z.b. Unterfürberg). Anschließend kann man den Router im WebUI erreichen und Koordinaten sowie Kontaktadresse und weitere Infos setzen.

Per Kabel

Der Ablauf ist ähnlich wie beim WLAN-Meshrouter. Der Meshrouter hat jedoch bereits Zugang zur Hood, denn er ist per Kabel direkt mit dem Batman-Port des Meshpartners verbunden. Er läd sich daher das Konfigurationfile nicht vom Hidden Accesspoint, sondern direkt vom Gateway der Hood. Die anschließende Konfiguration geschieht genauso wie per WLAN.

Regelmäßiges Aktualisieren der Hoodinformation

Da sich Hoods ändern können (neues Gateway kommt dazu, Rechtschreibfehler aus SSID verbessert, Kanal geändert, etc.), muss jeder Router regelmäßig nach neuen Hoodfiles suchen.

Uplinkrouter

Uplinkrouter fragen alle 5 Minuten den KeyXchangeV2 ab und prüfen, ob es dort eine neuere Version der Hoodinformationen gibt.

Meshrouter

Meshrouter haben keinen Zugang zum KeyXchangeV2. Daher wird dort über ein Anycast von fe80::1 auf Port 2342 von den Gateways regelmäßig das Hoodfile bezogen. Auf den Gateways wird die fe80::1 per nodad an das Batman angehängt, um ein Anycast System aufzubauen. Die Gateways beziehen diese Konfigurationfile regelmäßig vom KeyXchangeV2.

Hoodtrennung

Sollte es zu einer Trennung der Hood kommen und eine Wolke in eine neue Hood umziehen, merken dies zuerst die Uplinkrouter, da sie vom KeyXchangeV2 ein neues Hoodfile bekommen. Nachdem sie sich damit neu konfiguriert haben, haben Meshrouter kein Gateway mehr in Reichweite (batctl gwl ist leer). Mit dieser Information starten sie ihre Hoodkonfiguration, wie oben beschrieben neu. Die hinterlegten Informationen wie Koordinaten, E-Mail, etc. bleiben dabei natürlich erhalten.

Gefahren eines Updates vom alten System

Alte Freifunkrouter werden aufgrund der Kompatibilitätsbrüche nicht mehr mit dem neuen System meshen können. Gerade bei größeren Installationen ist daher Vorsicht geboten. Es macht Sinn, von hinten in der Kette der Meshrouter mit dem Update zu beginnen und sich nach vorne bis zum Uplinkrouter vor zu arbeiten. Ob ein Remoteupdate halbwegs sicher durchzuführen ist, ist zum aktuellen Zeitpunkt nicht abschließend getestet. Ein Update vor Ort ist einen Remoteupdate immer vorzuziehen.

fd43:*** Adressen

Es wurden neue IPv6 ULA-Adressen eingeführt. Diese Adressen werden, wie auch der komplette fc00::/7 ULA-Raum, in unserem Freifunknetz geroutet. Jeder Router bekommt über die Hoodfiles mitgeteilt, welches /64 er nutzen soll und konfiguriert sich eine Adresse auf br-mesh. Diese ist auch im Monitoring zu sehen. Da diese Adressen geroutet werden, ist darüber ein Zugang im kompletten Freifunknetz (später auch über ICVPN) möglich und nicht nur in der selben Hood. Freifunkclients bekommen so eine Adresse über radvd von den Gateways zugesteckt(?!), ohne Default-Route aber mit fc00::/7 als Route. Natürlich können auch Clients über dieses Netz freifunkweit per IPv6 kommunizieren.

fdff:: Adressen

Hier bleibt alles beim Alten. Diese Adressen werden direkt vom Knoten vergeben, somit ist ein Knoten auch ohne Hoodkonfiguration über seine fdff::MAC oder fdff::1 erreichbar. Diese Adressen gelten nach wie vor nur in der gleichen Hood, auch fdff::1 bleibt als Sonderadresse bestehen und bezieht sich immer auf den aktuell verbundenen Knoten. Zum aktuellen Zeitpunkt sind u.U. Knoten ohne Konfiguration nicht per WLAN, sondern nur per Kabel zu erreichen.

Sectorfile

(Achtung! Diese Anleitung hab ich gerade aus dem Kopf heraus verfasst, bitte noch mal in der Praxis prüfen!)

Mit dem Sektorfile ist es nun möglich, auf einzelnen "Sektoren" den Kanal o.ä. zu ändern. In unserem Beispiel machen wir das nur mit dem Kanal, theoretisch wäre das aber auch mit anderen Informationen, die im JSON-File stehen, möglich.

Der Sektor ist damit eine Untereinheit einer Hood, die per Funk-Mesh verbunden ist. Die Grenzen des Sektors sind die Grenzen des Funknetzes (also z.B. reine Kabel-Verbindungen).

Notwendige Konstellation

Damit auf einzelnen Sektoren der Kanal geändert werden kann, muss folgendes bedacht werden:

Es muss einen Initial-Router geben.
- Dieser Initial-Router muss entweder per WAN einen Uplink haben oder Batman per Kabel bekommen. Bei reinen WLAN-Meshroutern macht eine Kanaländerung keinen Sinn.
- Dieser Initial-Router gibt den Sektorkanal vor, alle WLAN-Meshrouter, die sich von diesem Router das JSON-File holen, werden sich auf den neuen Kanal konfigurieren.

Beispiel

Beispiel einer sinnvollen Konstellation:

Auf einen Kirchturm ist ein "Uplink-Router", dabei ist es egal, ob er dezentrales Gateway ist, Batman per Kabel bekommt oder WAN-Uplink hat.
An diesem "Uplink-Router" hängen 4 Sektorgeräte (z.b. NSM2) mit Freifunkfirmware, in jede Himmelsrichtung eines. Diese Sektorgeräte möchte man nun auf 4 verschiedene Kanäle (1, 5, 9, 13) legen. Ein Meshrouter würde sich im normalfall auf den Kanal konfigurieren, der per JSON-File, das in der Hood verteilt wird, konfiguriert ist. Es macht nun Sinn, diese Sektorfiles auf jeder dieser 4 Sektorantennen anzulegen, jeweils mit dem Kanal, den man für das Gerät vorgesehen hat.
Wenn sich nun ein WLAN-Meshrouter unten im Geschäft an der Straße über das Gerät mit Kanal 5 die keyxchangev2data json holt, holt er sich gleich noch das Sektorfile mit, in welchem der Kanal 5 steht und konfiguriert sich dann automatisch auf Kanal 5. So kann an jeden Sektor ohne manuelle Konfigurieren gemesht werden.

Bilder [...]TBD[...]

Anlegen der Sektorfile

Nachdem auf einem Sektorgerät der Kanal geändert wurde, muss das File /etc/sectorfile angelegt werden. Hier wird nur die Information hinterlegt, die vom hoodweiten keyxchangev2data-File überschrieben werden soll, als gültige JSON, in unserem Fall der Kanal von 2,4GHz auf Kanal 5.

Die File müsste so aussehen:

{
	"hood": {
		"channel2": "5"
	}
}

Bitte immer prüfen, ob das json-File valide ist, z.b. mit https://jsonlint.com/

Danach wird es an Meshrouter ausgeliefert. Alle Meshrouter, die sich nun genau von dieser Sektorantenne das json-File holen, werden sich anschließend auf Kanal 5 konfigurieren. Diese Meshrouter liefern nun automatisch das erweitere JSON-File aus, so dass auch die nächsten Meshrouter auf Kanal 5 arbeiten. Dies geschieht solange, bis die Kette durch eine Kabelverbindung unterbrochen wird. Der Knoten, der per Kabel am Netz hängt, fällt auf den Kanal zurück, den die Hood vorgibt (das macht Sinn und ist so gewollt).

Sourcecode: https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood

https://github.com/FreifunkFranken/firmware/commit/3f607e106f842e58dcbc07cc1cf28b1e15b388c5

FAQ

Frage:

Wenn jede Hood eine eigene SSID hat, dann muss ich mir ja 100 SSID im Handy speichern und niemand findet mehr das Freifunknetz

Antwort: Es hat sich in der Praxis gezeigt, das User eine neue SSID sehr schnell finden [2] oder [3] Zudem ist es technisch gesehen einfach richtig, das jedes Layer2-Netz eine eigene SSID hat. Und seien wir mal ehrlich, hält man sich wirklich in 100 verschiedene Hoods auf? Selbst in Fürth mit den vielen dezentralen Hoods sind es meist doch immer die gleichen 3-5 Bereiche und soviele SSIDs sollten moderne Handys problemlos verkraften ;)