(Falls ich hier falsch bin, bitte verschieben)
Kurze Frage,
gibt es irgendwelche Ideen/Ansätze, bezüglich MeshOnLAN-Knoten, welche definitiv nicht in WLAN-Reichweite von anderen FF-Routern sind?
(Falls ich hier falsch bin, bitte verschieben)
Kurze Frage,
gibt es irgendwelche Ideen/Ansätze, bezüglich MeshOnLAN-Knoten, welche definitiv nicht in WLAN-Reichweite von anderen FF-Routern sind?
Hallo @Jason,
ich habe deinen Beitrag mal in ein neue Thema verschoben.
Was meinst du mit weit entfernt? LAN-Mesh bedeutet, dass die Geräte über Kabel verbunden sind. Da kannst du nach Ethernetstandard und guten Kabeln etwas über 100 Meter erreichen. Wenn du nach den 100 m einen Switch (oder einen weiteren 841er, was meist billiger ist) aufstellst, kannst du nochmal 100 m überbrücken. Das ist kein Problem, die Geräte müssen sich nicht per WLAN sehen können, Kabel ist eh besser.
Eine solche Installation habe ich z. B. hier gebaut: https://karte.freifunk-muensterland.de/map01/#!v:m;n:30b5c2d99a3e
Die beiden Knoten stehen quasi an verschiedenen Enden des Büros und sind über eine umgepatchte Dose verbunden.
Viele Grüße
Matthias
Was soll denn Deiner Meinung dann passieren? Andere Hood auswählen? Oder meshing per Vlan-ID unterbinden? Oder auf Batmanebene bzw dem übergeordneten vswitch zum eth0/1 mit Ebtables was verhindern? Und wenn ja, warum? Stört das?
Es geht mir um die Umstellung des Mesh-Protokolls, z.B. die Umstellung von Batman v14 auf XY.
Da gibt es ja u.a. ein Fallback-Helferskript-Package (siehe Batman v14 zu v15 upgrade - gluon package) um verlohrengegangene Router per WLAN wieder einzufangen. Dieses Package wirkt aber eben nur bei Wifi-Meshes.
Mir stellt sich daher die Frage, ob es für Mesh-Wolken, welche hauptsächlich per MeshOnLAN meshen, auch bereits einen theoretischen Lösungsansatz einer Mesh-Protokoll-Umstellung gibt?
Beispiel einer solchen Mesh-Wolke: Meshviewer - loading... ( blauer Link = MoL, grüner Link = IBSS )
Ah okay, hab ich überhaupt nicht in dem Zusammenhang gesehen.
Das geht leider nicht. Um sich zu verbinden, bräuchte der Knoten das andere Meshprotokoll, was er selbst nicht hat.
interessanter usecase, wenn die Anzahl der Uplinkrouter an denen die reinen MeshonLan Router hängen überschaubar ist, und diese auch eh „speziell“ sind könnte man sich für diese eine spezielle Lösung einfallen lassen.
Ansonsten ists wie @MPW sagte, man kann in der Regel nur eine Variante von Batman sprechen, bei dem Skript von mir wird quasi ausgenutzt das die Router ja auch einen normalen Client spielen könnten und sich so ihren uplink selber machen. Da sie dabei Freifunk durch Freifukn machen ist das nur eine Notlösung fürs Updaten.
Ein alternativer Weg könnte sein , den Meshenden Knoten irgendwie Uplink via Kabel zu geben, aber das hängt total von den Einzelfällen ab, ob das überhaupt geht oder sinnvoll ist. Wobei ich jetzt nicht wüsste woher der uplinkknoten einen batv14 meshonlan linkenden knoten erkennen sollte.