KeyXchangeV2: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(Link-Formatierung)
 
(85 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Erklärung ==
== Erklärung ==
Mit dem KeyXchangeV2 werden den Routern nicht nur VPN Endpunkte wie bisher genannt sondern die komlette Routerkonfiguration. Somit weiß ein Router in welcher Hood er ist und kann sich dementsprechend konfigurieren. Eine solche Konfiguration sieht etwa so aus:
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:
* [http://keyserver.freifunk-franken.de/v2/?lat=49&long=11]
* [http://keyserver.freifunk-franken.de/v2/?lat=49&long=11 Konfigurationsdatei (Beispiel)]
Da wir eh die kompatiblität zum alten System brechen, werden auch einige Systeme aktualisiert:
Da KeyXchangeV2 zum alten System nicht kompatibel ist, werden auch einige Systeme aktualisiert:
* Batman Compat v15
* [[B.A.T.M.A.N.|batman-adv]] compat v15
* 11s statt IBSS Mesh
* IEEE 802.11s statt IBSS Mesh
Grundsätzlich kann man sich das v2 Netz als komplett neues Netz vorstellen, so gibt es auch wieder neue Grenzlinien der Hoods welche rechts oben auf der Monitoringkarte mit einem Klick auf den Papierstapel und einen Haken bei HoodV2 eingeblendet werden können. Alte Router meshen nicht mit neuen oder andersherum. Eine Kommunikation zwischen alten und neuen Hoods ist auf IPv4 Basis möglich. Auch die Aufteilung der Hoods wird von vorne gestartet. Je mehr Router in die neuen Hoods umgezogen werden, desto mehr Hoods müssen dort erstellt werden und je kleiner die alten Hoods werden, desto mehr Hoods kann man im alten System auflösen bis es dort nur noch eine hand voll Router in der letzten default Hood geben wird.
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 „Hoods V2“ 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 ==
== Vorteile ==
* Verschiedene Hoods können nicht mehr miteinander meshen
* Verschiedene Hoods können nicht mehr miteinander meshen
* SSID ist für jede Hood einzigartig (nach RFCXXXX richtig das jedes L2 Netz eine eigene SSID hat)
* Jede Hood hat eine eigene SSID
* Router können Hoodübergreifend erreicht und konfiguriert werden (über nun routbare fd43:*** Adressen)
* Router können hoodübergreifend erreicht und konfiguriert werden (über nun routbare fd43:-Adressen).
* Es wird auf den Gateways nicht mehr der Key des Routers geprüft. Somit kann jede Hood auch manuell ohne KeyXchange betreten werden!
* 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
* Das Monitoring bekommt die Daten dezentral von den Gateways und nicht mehr zentral von der NetmonVM.
* Neue Hoods sind deutlich leichter anzulegen
* Neue Hoods sind deutlich leichter anzulegen.
** NetmonVM muss nicht mehr angepasst werden
** 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.
** 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 diesen aber an. Wer jetzt schon dezentral sein möchte, kann dies problemlos machen wie div. Hoods (StPaul, Marterlach, Stmarkus, Unterfürberg, Hardhöhe, Neunhof, FabLabnbg, etc.) beweisen.
* Allgemein wurde das System so entwickelt, dass es eine Vorstufe zum dezentralen KeyXchange wird. Dieses System ist weiterhin noch nicht 100 Prozent 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.
** Zum aktuellenm Zeitpunkt ist aber unklar ob der dezentrale KeyXchange überhaupt irgendwann entstehen wird. Mittlerweile hat sich gezeigt, dass die komplette dezentralität mit einer dezentralen Hood viel leichter zu erreichen ist: https://wiki.freifunk-franken.de/w/Dezentrale_Hood Wer also zum aktuellen Zeitpunkt komplett dezentral sein möchte kann dies bereits tun und es wird schon fleißig getan.


== Informationen ==
== Informationen ==


=== Inbetriebname Uplinkrouter ===
=== Inbetriebnahme Uplinkrouter ===
Nach dem flashen, den Router wie bisher auch mit dem blauen Port zum Internet verbinden. Nach einiger Zeit sollte er eine SSID mit den Namen trainstation.freifunk ausstrahlen (kann u.U. etwas länger dauern 5 Minuten oder so sind beim ersten boot keine Seltenheit). Mit dieser kann man sich verbinden und den Router wie bisher auch erreichen zum konfigurieren. In dieser Hood ist kein Zugang zum Internet möglich, es handelt sich nur um eien Trainstation. Um diese zu verlassen müssen Koordinaten gesetzt werden damit er in einer gültigen Hood landet.
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! Fünf 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.  
Zu einigen Seiten ist der Zugang dennoch möglich:
Einige Freifunk-Seiten sind dennoch erreichbar:
* Monitoring
* Monitoring
* Freifunk Franken Wiki
* Freifunk Franken Wiki
* OSM Karte damit im WebUI des Routers auch die Karte läd
* OSM-Karte, damit im WebUI des Routers auch die Karte geladen wird.
Nach den setzen der Koordinaten sollte der Knoten eine SSID in der Art: STADT.freifunk(.net) ausstrahlen und darüber ist dann normaler Zugang zum Freifunknetz und Internet möglich
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.


=== Inbetriebname Meshrouter ===
=== Inbetriebnahme Meshrouter ===


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


Wenn nun ein Meshrouter einfach aufgestellt wird und er selbst feststellt, das er am WAN Port kein Internet hat, sucht er selbstständig nach diesem versteckten Netz und holt sich dort die Konfiguration. Anschließend wendet er diese Konfiguration an und ist absofort als Meshrouter in dieser Hood aktiv. Dies funktioniert auch problemlos mit dezentralen Hoods sofern sie schon soweit aktualisiert sind (z.b. Unterfürberg).
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.
Anschließend kann man den Router ganz normal im WebUI erreichen und Koordinaten sowie Kontatadresse und weitere Infos setzen.


==== Per Kabel ====
==== 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 B.A.T.M.A.N.-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.


Dies geschieht ähnlich wie bei dem WLAN Meshrouter, nur das dieser Router bereits Zugang zur Hood hat (er ist per Kabel direkt mit Batman verbunden) und läd sich daher die Konfigurationfile nicht vom Hidden AP 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.
=== Regelmäßiges aktualisieren der Hoodinformation ===
Da sich Hoods durchaus aktualisieren können (neues Gateway kommt dazu, Rechtschreibfehler aus SSID verbessert, etc.). muss jeder Router regelmäßig nach neuen Hoodfiles suchen.


==== Uplinkrouter ====
==== Uplinkrouter ====
Uplinkrouter fragen ganz normal alle 5Minuten den KeyXchangeV2 an und prüfen ob es dort eine neuere Version gibt
Uplinkrouter fragen alle fünf Minuten den KeyXchangeV2 ab und prüfen, ob es dort eine neuere Version der Hoodinformationen gibt.


==== Meshrouter ====
==== Meshrouter ====
Meshrouter haben keinen Zugang zum KeyXchangeV2. Daher wird dort über ein Anycast von fe80::1 auf Port 2342 von den Gateways regelmäßig die Hoodfile bezogen.
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 gehangen um ein Anycast System aufzubauen. Die Gateways beziehen diese Konfigurationfile regelmäßig vom KeyXchangeV2.
Auf den Gateways wird die fe80::1 per nodad an das B.A.T.M.A.N. angehängt, um ein Anycast-System aufzubauen. Die Gateways beziehen diese Konfigurationfile regelmäßig vom KeyXchangeV2.


=== Hoodtrenung ===
Da gelegentlich andere Geräte im Layer-2-Netz die IP fe80::1 besitzen, wird gerade versucht, diese auf fe80::fff:1 zu ändern. Am oben beschriebenen Prinzip ändert sich nichts.


Sollte es zu einer Hoodtrennung kommen und eine Wolke in eine neue Hood umziehen, merken dies zuerst die Uplinkrouter da sie vom KeyXchangeV2 eine neue Hoodfile bekommen. Nachdem diese sich neu konfiguriert haben, haben Meshrouter kein Gateway mehr in Reichweite (batctl gwl ist leer), anhand dieser Information starten sie ihre Hoodkonfiguration wie oben beschrieben erneut. Hinterlegte Informationen wie Koordinaten, E-Mail, etc. bleiben dabei natürlich erhalten
=== 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 ===
=== Gefahren eines Updates vom alten System ===
Alte Freifunkrouter werden aufgrund der gebrochenen kompatibilität nicht mer mit dem neuen System meshen können. Gerade bei größeren Installationen ist daher vorsicht geboten. Es macht Sinn von "hinten" in der Kette mit dem Update anzufangen und sich nach vorne in der Kette bis zum Uplinkrouter vorzuarbeiten.
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.
Ob ein Remoteupdate halbwegs sicher ist, kann zum aktuellen Zeitpunkt nicht gesagt werden. Ein Update vor Ort ist einen remote Update aber eindeutig immer vorzuziehen.
 
Es ist auch nicht möglich, von v1 Routern auf v2 Router zu kommen und umgekehrt. Für ein Remote Update ist somit ein v1 Router nötig, um die anderen v1 Router zu erreichen.
 
Empfohlen wird:
# Neustart des Routers vor dem Update
# Beim Update in der Kette der Meshrouter '''von hinten beginnen''', <br> und sich '''nach vorne bis zum Uplinkrouter''' vorarbeiten.
 
Ein Remote-Update kann prinzipiell durchgeführt werden. Allerdings entstehen  Schwierigkeiten, wenn bei einem der Router das Update nicht funktioniert oder der Zugriff nicht auf alle Mesh-Router möglich ist.
 
Dann hilft manchmal, einfach etwas zu warten (30 Minuten), oder den Router vor Ort neu zu starten.  
 
Wenn gar nichts mehr geht:
* Unbricken für TP-Link TL-WR841N/ND: da hilft [[wikipedia:de:TFTP|TFTP]]
* [[Unbricken_eines_TP-Link_1043ND|Unbricken für TP-Link TL-WR1043N]]
* siehe auch: [[Anleitungen#Beim_Update_ging_etwas_komplett_schief|Beim Update ging etwas komplett schief]]
 
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 /64er 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.


=== fd43:*** Adressen ===
=== fdff::-Adressen ===
Es wurden neuen IPv6 ULA Adressen eingeführt. Diese Adressen werden wie auch der komplette fc00::/7 ULA Raum in unseren Freifunknetz geroutet. Jeder Router bekommt über die Hoodfile 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 gleichen Hood.
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.&nbsp;U. Knoten ohne Konfiguration nicht per WLAN, sondern nur per Kabel zu erreichen.
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 Cliens über dieses Netz Freifunkweit per IPv6 kommunizieren.


=== fdff:: Adressen ===
=== Hood festsetzen ===
Hier bleibt alles beim alten. Diese Adressen werden direkt vom Knoten vergeben und somit ist ein Knoten auch komplett 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 zeigt immer auf den aktuell verbundenen Knoten. Zum aktuellen Zeitpunkt sind u.U. Knoten ohne Konfiguration nicht per WLAN sondern nur per Kabel zu erreichen.
 
Achtung, dies muss auch auf allen Meshroutern gemacht werden. Die Hoodfile wird nicht zum automatisch konfigurieren angeboten!
 
Details zum Hoodfile unter: [[Hood file]]
 
Mit dem KeyXchangeV2 ist es nun auch möglich eine Hood unabhängig von der Position zu betreten. Vorteil weiterhin, dass man nicht mehr vom KeyXchangeV2 abhängig ist, sondern manuell festlegt, wo man sich hin verbinden möchte (dezentral!). Man sollte dies allerdings nur tun, wenn man genau weiß, was man tut, da man absofort auch keine Updates mehr vom KeyXchangeV2 bekommt. Wenn sich z.&nbsp;B. Gateways ändern, wird dies mit einer festen Hoodfile nicht aktualisiert! Sinnvollerweise sollte dies nur verwendet werden, wenn man die Hood selbst betreibt z.&nbsp;B. bei [[Dezentrale Hood|dezentralen Hoods]].
 
Um dies zu verwenden, muss nur eine valide Hoodfile nach „/etc/hoodfile“ gelegt werden. Diese wird vorrangig vor jedem anderen System verwendet. Aufgrund eines Bugs muss der Router nach anlegen der File neu gebootet werden (Strom aus/an).
 
Eine Erweiterung im Webinterface soll nach dem Release diskutiert werden.
 
Um eine passende Hoodfile zu finden, kann diese Seite verwendet werden:
http://keyserver.freifunk-franken.de/v2/hoods.php


=== Sectorfile ===
=== Sectorfile ===
<div style="width:fit-content; margin-bottom:1em; padding:0.5em 2em; background-color:#ff4500; color:#000;">
'''Das Sectorfile ist im aktuellen Release nicht enthalten!'''
</div>


(Achtung! Diese Anleitung hab ich gerade aus dem Kopf heraus verfasst, bitte noch mal in der Praxis prüfen!)
<div class="mw-collapsible mw-collapsed">
Mit dem Sektorfile ist es nun möglich, auf einzelnen „Sektoren“ den Kanal o.&nbsp;ä. 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. (Bestimmte Parameter, z.&nbsp;B. die SSIDs, können so aber nicht ohne ernste Probleme verändert werden).


Mit der 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ären aber auch andere Informationen die in der JSON File stehen möglich.
Der Sektor ist damit eine Untereinheit einer Hood, die per Funkmesh verbunden ist. Die Grenzen des Sektors sind die Grenzen des Funknetzes (also z.&nbsp;B. reine Kabelverbindungen).


==== Notwendige Konstellation ====
==== Notwendige Konstellation ====


Damit auf einzelnen Sektoren der Kanal geändert werden kann, muss folgendes bedacht werden:
Damit auf einzelnen Sektoren der Kanal geändert werden kann, muss folgendes bedacht werden:
* Es muss einen Initial-Router geben.
* Es muss einen Initialrouter geben.
** Dieser Initial-Router muss entweder per WAN Uplink haben oder Batman per Kabel bekommen, bei reinen WLAN-Meshrouter macht eine Kanaländerung keinen Sinn.
** Dieser Initialrouter muss entweder per WAN einen Uplink haben oder B.A.T.M.A.N. per Kabel bekommen. Bei reinen WLAN-Meshroutern macht eine Kanaländerung keinen Sinn (der Router wäre dann isoliert!).
** Dieser Initial-Router gibt den Sektorkanal vor, alle WLAN Meshrouter die sich von diesem Router die JSON File holen werden sich auf den neuen Kanal konfigurieren
** Dieser Initialrouter 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 ======


Beispiel einer sinnvollen Konstellation:
Beispiel einer sinnvollen Konstellation:
* Auf einen Kirchturm ist ein "Uplinkrouter" dabei ist es egal ob er dezentrales Gateway ist, Batman per Kabel bekommt oder WAN Uplink hat.
* Auf einen Kirchturm ist ein „Uplinkrouter“, dabei ist es egal, ob er dezentrales Gateway ist, B.A.T.M.A.N. per Kabel bekommt oder WAN-Uplink hat.
* An diesen "Uplinkrouter" hängen 4 Sektorgeräte (z.b. NSM2) mit Freifunkfirmware in jede Blickrichtung der Kirche, 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 den die JSON die in der Hood verteilt wird eingestellt ist. Es macht nun Sinn diese Sektorfile auf jeden dieser 4 Sektorantennen anzulegen, jeweils mit dem Kanal den man auf der Antenne einstellt.  
* An diesem „Uplinkrouter“ hängen vier Sektorgeräte (z.&nbsp;B. Ubiquiti NanoStation M2) mit Freifunkfirmware, in jede Himmelsrichtung eines. Diese Sektorgeräte möchte man nun auf vier 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 vier 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 auf der Antenne mit Kanal 5 die keyxchangev2data json holt, holt er sich gleich noch die Sektorfile mit, in welcher der Kanal 5 steht und konfiguriert sich dann automatisch auf Kanal 5. So kann an jeden Sektor ohne manuelle Konfigurieren gemesht werden.
* 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 ====
==== Anlegen der Sektorfile ====


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


Die File müsste so aussehen:
Die File müsste so aussehen:
Zeile 103: Zeile 138:
</pre>
</pre>


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


danach wird diese an Meshrouter ausgeliefert. Alle Meshrouter die sich nun genau von dieser Sektorantenne die json holen werden sich anschließend auf Kanal 5 konfiguren, auch diese Meshrouter liefern automatisch wiederrum die erweitere JSON aus so das auch die nächsten Meshrouter auf Kanal 5 bleiben, dies geschieht solange bis die Kette durch eine Kabelverbindung unterbrochen wird, danach fällt der Knoten der per Kabel dran hängt wieder auf den Kanal zurück den die Hood vorgibt (macht auch Sinn und ist so gewollt).
Anschließend muss auf dem Router wo die json händisch angelegt wurde die Hoodkonfiguration neu geladen werden. Z.&nbsp;B. indem man per SSH folgende Befehle ausführt:


Sourcecode: https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
<pre>
rm /tmp/hoodfileref
rm /tmp/hoodfilewww
configurehood
</pre>


https://github.com/FreifunkFranken/firmware/commit/3f607e106f842e58dcbc07cc1cf28b1e15b388c5
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 auf Github:
: https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
: https://github.com/FreifunkFranken/firmware/commit/3f607e106f842e58dcbc07cc1cf28b1e15b388c5
 
</div>


== FAQ ==
== FAQ ==


Frage:
=== Frage: Warum haben wir jetzt keine einheitliche SSID mehr, so wie früher mit „franken.freifunk.net“? ===
=== Wenn jede Hood eine eigene SSID hat, dann muss ich mir ja 100 SSID ims Handy speichern und niemand findet mehr das Freifunknetz ===
 
Das Problem ist, das beim V2 versucht wird, die Hoods extrem klein zu machen. So kann es vorkommen das verschiedene Hoods direkt nebeneinander existieren. Wenn man sich nun „zwischen“ den zwei Hoods aufhält, kann es passieren das ein Endgerät (z.&nbsp;B. Handy) sich mal in Hood A und mal in Hood B einbucht, wenn in beide Hoods die SSID gleich ist. Im besten Fall gehen nur kurz Verbindungen verloren (Downloads brechen ab etc.) im schlimmsten Fall weiß das Handy gar nicht, dass es in der falschen Hood ist und behält die IP aus der anderen Hood, so dass gar keine Kommunikation mehr zustande kommt.
 
Technisch gesehen ist es einfach richtig, dass jedes Layer-2-Netz (jede Hood) eine eigene SSID bekommt.
 
Ein weiterer Vorteil ist, dass die SSID mehr Bezug zu einer Stadt/einem Standort haben kann. So gibt es in Nürnberg/Fürth mittlerweile sehr kleine Hoods, die nur einzelne Kirchen (z.&nbsp;B. StPaul oder StMarkus), Ortsteile (z.&nbsp;B. Unterfürberg) oder Gegenden (z.&nbsp;B. Knoblauchsland) beschreiben.
 
=== 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:
Antwort:
Es hat sich in einigen Bereichen schon in der Praxis gezeigt, das User eine neue SSID sehr schnell finden [http://lists.freifunk.net/pipermail/franken-freifunk.net/2017-October/013673.html] oder [https://monitoring.freifunk-franken.de/routers/590ed2b29369c305f2b9c41d]
Es hat sich in der Praxis gezeigt, dass User eine neue SSID sehr schnell finden [http://lists.freifunk.net/pipermail/franken-freifunk.net/2017-October/013673.html]
Zudem ist es technisch gesehen einfach rchtig, das jedes Layer 2 Netz eine eigene SSID hat. Und seien wir mal ehrlich, hälst du dich 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 ;)
Zudem ist es technisch gesehen einfach richtig, das jedes Layer-2-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 drei bis fünf Bereiche und soviele SSIDs sollten moderne Handys problemlos verkraften.
 
=== Frage: Ich wohne in Stadt XYZ sehe aber die SSID von Stadt ABC, was kann ich tun? ===


Frage:
Hier gibt es mehrere Möglichkeiten:
=== Ich seh nur so eine Sperrseite, was kann ich tun? ===
* Es kann eine [[Dezentrale Hood|dezentrale Hood]] angelegt werden.
* Es kann eine neue V2-Hood angelegt werden, dazu wird mindestens ein [[Freifunk-Gateway aufsetzen|Gateway benötigt]], besser wären zwei. Dann einfach an einen KeyXchange-Admin wenden damit die Hood angelegt wird.
* Falls es Stadt XYZ schon gibt, du aber so ungünstig wohnst das SSID ABC angezeigt wird, kann auch die Hood manuell betreten werden. Dies geschieht indem man die [[KeyXchangeV2#Hood festsetzen|Hoodfile einfach fest setzt]].
Achtung: Bei Änderungen der Hood, muss dies manuell geschehen. Sollten sich z.&nbsp;B. die Gateways ändern muss dies selbstständig eingetragen werden.
 
=== Frage: Ich möchte nicht, dass sich meine SSID bei jeder Hoodänderung ändert, was kann ich tun? ===
 
* Es kann eine dezentrale Hood angelegt werden, somit hast du die volle Kontrolle über dein Netz: [[Dezentrale Hood]]
* Du kannst eine statische Hoodfile verwenden: [[KeyXchangeV2#Hood festsetzen|KeyXchangeV2 – Hood festsetzen]]
 
=== Frage: Ich seh nur so eine Sperrseite, was kann ich tun? ===
 
Antwort:
In der Trainstation ist kein Internet möglich. Bitte setze im Router-Webinterface gültige geografische Koordinaten, damit das Gerät sich mit der richtigen Hood verbindet.
 
=== Frage: Wie wähle ich als Gateway-Betreiber eine sinnvolle SSID? ===
 
Siehe: [[Hood file#Wie finde ich eine sinnvolle SSID|Hood file – Wie finde ich eine sinnvolle SSID?]]
 
=== Frage: Meshrouter wechseln ständig die Hood ===


Antwort:
Antwort:
In der Trainstation ist kein Internet möglich. Bitte setze im Routerwebinterface Koordinaten damit er sich in eine richtige Hood verbindet.
Hier gibt es mehrere Möglichkeiten:
* Fehlerhafte Anzeige des Monitorings. Zuerst sollte geprüft werden, ob dies echt so ist oder nur ein Anzeigefehler im Monitoring (gerade wenn er von V2 zu V1 und wieder auf V2 wechselt, ist es sehr sicher ein Anzeigefehler).
* Wenn Meshrouter nur per WLAN angebunden sind, kann es passieren, dass in der Nähe zwei verschiedene Hoods sind. Im ungünstigen Fall wechseln die Router dann ständig die Hood hin und her. U.&nbsp;U. ist der Router der zweiten Hood auch falsch platziert, so dass der „falsche Nachbarrouter“ im Monitoring gar nicht sichtbar ist (da die Position ja falsch ist, ist er auch im Monitoring irgendwo ganz wo anders). Dies kann man durch einen WLAN Scan in der nähe prüfen. Sonstige Lösung: […]
* Auf einem Gateway der Hood wird eine falsche Hoodfile ausgeliefert. Dies kann bewiesen werden, wenn per SSH auf einen Router „wget http://[fe80::1%br-mesh]/keyxchangev2data -O-“ aufgerufen wird und hier eine falsche Hoodfile geliefert wird. Da fe80::1 eine anycast-Adresse ist und irgendein Gateway antwortet, muss man dies u.&nbsp;U. sehr oft probieren bis man mal bei allen Gateways der Hood herausgekommen ist. Falls dies auffällt, sollten umgehend die Gatewaybetreiber der Hood kontaktiert werden, um dies zu prüfen!


= Weitere Inromationen =
= Weitere Informationen =
* https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2
* https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2
* https://wiki.freifunk-franken.de/w/Portal:Netz/IPv6
* https://wiki.freifunk-franken.de/w/Portal:Netz/IPv6
* https://wiki.freifunk-franken.de/w/Dezentrale_Hood
* https://wiki.freifunk-franken.de/w/Dezentrale_Hood
* https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
* https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
* [https://wiki.freifunk-franken.de/w/Gatewayfirmware Gatewayfirmware]
[[Kategorie:Technik]]
[[Kategorie:Hoods-V2]]
[[Kategorie:Firmware]]

Aktuelle Version vom 9. April 2020, 13: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:

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

  • batman-adv compat v15
  • IEEE 802.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 „Hoods V2“ 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
  • 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, dass es eine Vorstufe zum dezentralen KeyXchange wird. Dieses System ist weiterhin noch nicht 100 Prozent 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.
    • Zum aktuellenm Zeitpunkt ist aber unklar ob der dezentrale KeyXchange überhaupt irgendwann entstehen wird. Mittlerweile hat sich gezeigt, dass die komplette dezentralität mit einer dezentralen Hood viel leichter zu erreichen ist: https://wiki.freifunk-franken.de/w/Dezentrale_Hood Wer also zum aktuellen Zeitpunkt komplett dezentral sein möchte kann dies bereits tun und es wird schon fleißig getan.

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! Fünf 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 B.A.T.M.A.N.-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 fünf 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 B.A.T.M.A.N. angehängt, um ein Anycast-System aufzubauen. Die Gateways beziehen diese Konfigurationfile regelmäßig vom KeyXchangeV2.

Da gelegentlich andere Geräte im Layer-2-Netz die IP fe80::1 besitzen, wird gerade versucht, diese auf fe80::fff:1 zu ändern. Am oben beschriebenen Prinzip ändert sich nichts.

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 ist auch nicht möglich, von v1 Routern auf v2 Router zu kommen und umgekehrt. Für ein Remote Update ist somit ein v1 Router nötig, um die anderen v1 Router zu erreichen.

Empfohlen wird:

  1. Neustart des Routers vor dem Update
  2. Beim Update in der Kette der Meshrouter von hinten beginnen,
    und sich nach vorne bis zum Uplinkrouter vorarbeiten.

Ein Remote-Update kann prinzipiell durchgeführt werden. Allerdings entstehen Schwierigkeiten, wenn bei einem der Router das Update nicht funktioniert oder der Zugriff nicht auf alle Mesh-Router möglich ist.

Dann hilft manchmal, einfach etwas zu warten (30 Minuten), oder den Router vor Ort neu zu starten.

Wenn gar nichts mehr geht:

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 /64er 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.

Hood festsetzen

Achtung, dies muss auch auf allen Meshroutern gemacht werden. Die Hoodfile wird nicht zum automatisch konfigurieren angeboten!

Details zum Hoodfile unter: Hood file

Mit dem KeyXchangeV2 ist es nun auch möglich eine Hood unabhängig von der Position zu betreten. Vorteil weiterhin, dass man nicht mehr vom KeyXchangeV2 abhängig ist, sondern manuell festlegt, wo man sich hin verbinden möchte (dezentral!). Man sollte dies allerdings nur tun, wenn man genau weiß, was man tut, da man absofort auch keine Updates mehr vom KeyXchangeV2 bekommt. Wenn sich z. B. Gateways ändern, wird dies mit einer festen Hoodfile nicht aktualisiert! Sinnvollerweise sollte dies nur verwendet werden, wenn man die Hood selbst betreibt z. B. bei dezentralen Hoods.

Um dies zu verwenden, muss nur eine valide Hoodfile nach „/etc/hoodfile“ gelegt werden. Diese wird vorrangig vor jedem anderen System verwendet. Aufgrund eines Bugs muss der Router nach anlegen der File neu gebootet werden (Strom aus/an).

Eine Erweiterung im Webinterface soll nach dem Release diskutiert werden.

Um eine passende Hoodfile zu finden, kann diese Seite verwendet werden: http://keyserver.freifunk-franken.de/v2/hoods.php

Sectorfile

Das Sectorfile ist im aktuellen Release nicht enthalten!

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. (Bestimmte Parameter, z. B. die SSIDs, können so aber nicht ohne ernste Probleme verändert werden).

Der Sektor ist damit eine Untereinheit einer Hood, die per Funkmesh verbunden ist. Die Grenzen des Sektors sind die Grenzen des Funknetzes (also z. B. reine Kabelverbindungen).

Notwendige Konstellation

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

  • Es muss einen Initialrouter geben.
    • Dieser Initialrouter muss entweder per WAN einen Uplink haben oder B.A.T.M.A.N. per Kabel bekommen. Bei reinen WLAN-Meshroutern macht eine Kanaländerung keinen Sinn (der Router wäre dann isoliert!).
    • Dieser Initialrouter 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 „Uplinkrouter“, dabei ist es egal, ob er dezentrales Gateway ist, B.A.T.M.A.N. per Kabel bekommt oder WAN-Uplink hat.
  • An diesem „Uplinkrouter“ hängen vier Sektorgeräte (z. B. Ubiquiti NanoStation M2) mit Freifunkfirmware, in jede Himmelsrichtung eines. Diese Sektorgeräte möchte man nun auf vier 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 vier 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.

Anlegen der Sektorfile

Um auf einem Sektorgerät den Kanal zu ändern, muss das File „/etc/sectorfile“ angelegt werden. Hier wird nur die Information hinterlegt, die im hoodweiten keyxchangev2data-File überschrieben werden soll, als gültige JSON, in unserem Fall der Kanal von 2,4 GHz 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/

Anschließend muss auf dem Router wo die json händisch angelegt wurde die Hoodkonfiguration neu geladen werden. Z. B. indem man per SSH folgende Befehle ausführt:

rm /tmp/hoodfileref
rm /tmp/hoodfilewww
configurehood

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 auf Github:

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: Warum haben wir jetzt keine einheitliche SSID mehr, so wie früher mit „franken.freifunk.net“?

Das Problem ist, das beim V2 versucht wird, die Hoods extrem klein zu machen. So kann es vorkommen das verschiedene Hoods direkt nebeneinander existieren. Wenn man sich nun „zwischen“ den zwei Hoods aufhält, kann es passieren das ein Endgerät (z. B. Handy) sich mal in Hood A und mal in Hood B einbucht, wenn in beide Hoods die SSID gleich ist. Im besten Fall gehen nur kurz Verbindungen verloren (Downloads brechen ab etc.) im schlimmsten Fall weiß das Handy gar nicht, dass es in der falschen Hood ist und behält die IP aus der anderen Hood, so dass gar keine Kommunikation mehr zustande kommt.

Technisch gesehen ist es einfach richtig, dass jedes Layer-2-Netz (jede Hood) eine eigene SSID bekommt.

Ein weiterer Vorteil ist, dass die SSID mehr Bezug zu einer Stadt/einem Standort haben kann. So gibt es in Nürnberg/Fürth mittlerweile sehr kleine Hoods, die nur einzelne Kirchen (z. B. StPaul oder StMarkus), Ortsteile (z. B. Unterfürberg) oder Gegenden (z. B. Knoblauchsland) beschreiben.

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, dass User eine neue SSID sehr schnell finden [1] Zudem ist es technisch gesehen einfach richtig, das jedes Layer-2-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 drei bis fünf Bereiche und soviele SSIDs sollten moderne Handys problemlos verkraften.

Frage: Ich wohne in Stadt XYZ sehe aber die SSID von Stadt ABC, was kann ich tun?

Hier gibt es mehrere Möglichkeiten:

  • Es kann eine dezentrale Hood angelegt werden.
  • Es kann eine neue V2-Hood angelegt werden, dazu wird mindestens ein Gateway benötigt, besser wären zwei. Dann einfach an einen KeyXchange-Admin wenden damit die Hood angelegt wird.
  • Falls es Stadt XYZ schon gibt, du aber so ungünstig wohnst das SSID ABC angezeigt wird, kann auch die Hood manuell betreten werden. Dies geschieht indem man die Hoodfile einfach fest setzt.

Achtung: Bei Änderungen der Hood, muss dies manuell geschehen. Sollten sich z. B. die Gateways ändern muss dies selbstständig eingetragen werden.

Frage: Ich möchte nicht, dass sich meine SSID bei jeder Hoodänderung ändert, was kann ich tun?

Frage: Ich seh nur so eine Sperrseite, was kann ich tun?

Antwort: In der Trainstation ist kein Internet möglich. Bitte setze im Router-Webinterface gültige geografische Koordinaten, damit das Gerät sich mit der richtigen Hood verbindet.

Frage: Wie wähle ich als Gateway-Betreiber eine sinnvolle SSID?

Siehe: Hood file – Wie finde ich eine sinnvolle SSID?

Frage: Meshrouter wechseln ständig die Hood

Antwort: Hier gibt es mehrere Möglichkeiten:

  • Fehlerhafte Anzeige des Monitorings. Zuerst sollte geprüft werden, ob dies echt so ist oder nur ein Anzeigefehler im Monitoring (gerade wenn er von V2 zu V1 und wieder auf V2 wechselt, ist es sehr sicher ein Anzeigefehler).
  • Wenn Meshrouter nur per WLAN angebunden sind, kann es passieren, dass in der Nähe zwei verschiedene Hoods sind. Im ungünstigen Fall wechseln die Router dann ständig die Hood hin und her. U. U. ist der Router der zweiten Hood auch falsch platziert, so dass der „falsche Nachbarrouter“ im Monitoring gar nicht sichtbar ist (da die Position ja falsch ist, ist er auch im Monitoring irgendwo ganz wo anders). Dies kann man durch einen WLAN Scan in der nähe prüfen. Sonstige Lösung: […]
  • Auf einem Gateway der Hood wird eine falsche Hoodfile ausgeliefert. Dies kann bewiesen werden, wenn per SSH auf einen Router „wget http://[fe80::1%br-mesh]/keyxchangev2data -O-“ aufgerufen wird und hier eine falsche Hoodfile geliefert wird. Da fe80::1 eine anycast-Adresse ist und irgendein Gateway antwortet, muss man dies u. U. sehr oft probieren bis man mal bei allen Gateways der Hood herausgekommen ist. Falls dies auffällt, sollten umgehend die Gatewaybetreiber der Hood kontaktiert werden, um dies zu prüfen!

Weitere Informationen