Der Kirchturm hat vier Fenster in alle Himmelsrichtungen. In jedem Fenster hängt eine CPE510 mit der originalen PharOS Firmware als WDS konfiguriert. Alle CPE haben eine eigene SSID, eigenes WPA Kennwort und einen eigenen Kanal. Dies dient allerdings nicht als Schutz vor dem Zugriff, sondern als Schutz, damit nicht versehentlich die Brücke gestört wird. Die Zugangsdaten werden also bei Bedarf herausgegeben.
Über eine dieser CPE wird aktuell Internet in das Relais transportiert. Das ist etwas suboptimal. Eine dedizierte weitere M5 wäre vielleicht besser.
Gluon hatten wir zuerst aufgrund einer Empfehlung drauf, das ist aber natürlich nicht sinnvoll. Gluon beherscht nämlich kein DFS und kann deshalb nicht alle 5Ghz Kanäle nutzen und sendet auch mit stark verminderter Leistung.
Der einzige Nachteil besteht darin, dass einfaches meshen nicht möglich ist. Wenn ein Haushalt in der Umgebung des Relais sich daran anschließen möchte, muss dafür deren Hardware entsprechend eingestellt werden.
Ausserdem ist auf dem Kirchturm eine UBNT M5 Richtfunkantenne montiert, diese ist per WDS Brücke konfiguriert und stellt eine Punkt zu Punkt Verbindung zur etwas entfernten Geflüchtetenunterkunft her. Auch diese Verbindung ist zum Schutz der Verbindung mit einem Passwort versehen.
Alle Geräte sind an einen VLAN fähigen Switch angeschlossen. Wir haben den 8-Port Switch von TP-Link verwendet. Dieser beherscht das MTU-VLAN (Seite 26). MTU-VLAN hat nichts mit Maximum Transmission Unit zu tun, sondern ist die Abkürzung für Multi-Tenant Unit. Damit lässt sich verhindern, dass ein Port auf dem Switch mit einem anderen Port auf dem Switch kommunizieren kann, mit einer Ausnahme: Dem Port, der als MTU-Port angeben wird. Dieser sogenannte Uplink-Port kann mit allen anderen Ports kommunizieren. Hier haben wir einen Futro S550 angeschlossen. Der Futro hat lediglich mesh auf seinem Gigabit Port aktiviert und trennt so die Meshwolken. Dadurch hat man keine Loops im Netz, wenn man mehrere Relais verbunden hat. Auch entsprechen die BATMAN Links auf der Karte der Wirklichkeit, was die Fehlersuche vereinfacht.
Ich hoffe, aus dem Post könnt Ihr etwas für Euch mitnehmen! Über Feedback freue ich mich!
Sehr schönes Ding! Ich musste das mal nachbauen. Das Problem ist ja tatsächlich, wenn man die Richtfunkstrecken als Bridges verbindet, verbindet man zwei Switches und alle Knoten an allen Standorten sehen sich gleichzeitig und machen ein Wollknäuel, bei dem die angezeigten Batman-Links nichts mehr mit der physischen Realität zu tun hat.
Sehr schön auch zu sehen, was Du aus der Diskussion damals gemacht hast. Gute Arbeit.
Hier mal ein zwei entsprechend Konfigurierte Switche:
Das sind ein TP-SG108E und ein TP-SG2210P. Der 108 kann MTU direkt, da war das trivial umzustellen, der 2210 kann es nicht, da ging es nach längerem Ausprobieren über Port-basierte Switchregeln. VLANs waren da für mich eine Sackgasse.
Die Knoten in dem Dreieck meshen über Funk, die anderen hatten Mesh über WLAN abgestellt bekommen, damit die Verbindungen nur über das LAN besser hervortreten.
Und hier ein Wollknäuel, wenn man alle Knoten an die Switches hängt, ohne die entsprechend zu konfigurieren.
Hallo,
schöne Doku. Mal nachgefragt: werden die Clients bei Gluon ordnungsgemäß „übergeben“ wenn es zum Roaming kommt? Also Client wählt sich in Knoten A ein (erhält IP-Adresse etc.) und geht dann zu Knoten B. Bisher war meine Info das Knoten B dann immernoch zumindest eine ganze Weile erstmal zu Knoten A routetet der dann den Weg raus zum VPN organisiert. In dem Setup mit MTU würde das dann bedeuten das die Richtfunkstrecke mehrfach genommen wird weil sich die Knoten nicht gegenseitig sehen bevor ein Paket rausgeht.
Antwort lautet: Bei üblichen Site.Conf-Settings nicht, allenfalls zufällig und mit zusätzlichem Glück.
Was aber nicht die Schuld des Setups hier auf dem Turm ist.
Haben wir aber in mehreren Roaming-Threads besprochen.
Mein Wissensstand, und vielleicht kann jemand mehr zu sagen, oder mich korrigieren, ist, dass die Clients nicht übergeben werden. Sie buchen sich stattdessen in den neuen verfügbaren Access Point erst ein, wenn der alte wirklich gar nicht mehr geht. Beim Roaming hast du also das Problem, dass dein Endgerät immer an der alten schlechten Verbindung festhält. Das ist in manchen professionellen WLAN-Systemen mit zentralem Verwalter so gelöst, dass der alte AP Dich irgendwann herausschmeißt, wenn ein neuer besser erreichbar ist.
Die IP-Adresse kommt in unserem Netz nicht vom AP, auf dem Du sitzt, sondern von weiter Upstream, frag mich nicht nach Details. Daher ändert sich dann auch die Adresse nicht sofort, wenn Du den AP wechselst.
In einem reinen „Ich-will-Internet“-Szenario läuft der Verkehr von den Knoten über die Uplinks weg. Da hast Du meist nicht das Thema, dass Du noch mit dem alten Knoten Daten austauschst. Nimm an Du hast einen Kirchturm mit Sektorantennen und gehst um den herum. Dann bucht Dich Dein Endgerät in die Sektor-AP nacheinander ein. Der Datenverkehr geht dann von AP zu Switch über den MTU-Trunk zum Offloader. Von dort per VPN raus oder zurück über den gleichen Switch an eine Richtfunkstrecke. Der alte Sektor-AP ist aus dem Spiel.
Natürlich könnte man den AP sofort und ohne Zwischenstation mit der Richtfunkstrecke sprechen lassen, aber die werden (zumindest in 5GHz) häufig mit der normalen Firmware als Bridge betrieben. Die tun also so, als ob sie ein Kabel seien. Damit mesht Dein AP jetzt aber über LAN mit allen Knoten bei der Gegenstelle. Bei je vier Knoten pro Gegenstelle hast Du dann 8*7 Verbindungen. Das sind 56 Verbindungen für die BATMAN Päckchen verschickt und darstellt, wie gut die Verbindung ist. Das sieht erstmal nur unübersichtlich aus. Doof wird das bei mehr als zwei Relais, wenn dann ganz viele Verbindungen angezeigt werden, die aber nichts mehr mit der physischen Realität zu tun haben.
Der Link unter „Kirche“, „Geflüchtetenunterkunft“ und „Relais“ führt nur auf die FFRN Map.
Möglicherweise gibt es den damaligen Aufbau nicht mehr? Die Bilder von jfk helfen beim verstehen.
Ähnliche Szenarien sieht man ja beim klick auf das „Auge“ rechts oben.
