OK. Das funktioniert?
Ich mein’, auf dem Switch muss ja auch mein lokales Netz mit Verbindung zu meinem Provider zur Verfügung stehen, damit der stärkste Router da Mesh-VPN über seinen WAN-Port machen kann.
Irritieren die sich nicht gegenseitig?
Kann ich als Switch auch einfach das DSL-/Kabel-Modem von meinem Provider nehmen, wenn da noch Ports frei sind oder muss es ein Extra-Switch sein?
Mesh-on-LAN überlebt Autoupdate nicht? Wovon hängt eigentlich ab, ob eine Einstellung das Update überlebt?
Der ursprüngliche Post sagte, dass er auf den gelben LAN-Buchsen auch kein Client-LAN bekam, wenn ich ihn richtig verstanden habe.
Hmmm, irgendwie erscheint es mir unsauber, auf dem gleichen Switch sowohl das lokale Netzwerk als auch das Kabel-Meshen zu haben, aber wenn’s klappt. …
Edit: In diesem Thread klingt das auch so, als wenn einige der Meinung sind, dass man Batman-Traffic nicht auf dem an der WAN-Buchse hängenden privaten LAN haben, sondern die Netz-Segmente trennen möchte:
Also ich bin jetzt auch etwas verunsichert.
Ich habe hier eine NanoStation Loco M2 an der ich das VPN abgeschaltet und mesh via WAN eingeschaltet habe. Diese hängt nun mit einem Kabel an den gelben LAN Ports eines WDR4300 bei dem ich VPN Aktiviert habe, und mesh on LAN über die Konsole eingeschaltet habe. Nur der WAN Port des WDR4300 ist mit meinem eigentlichen LAN verbunden.
Ist das so richtig? Überlebt das Updates?
Sagt mal, hat jemand dieses Setup laufen und bekommt gute Performanz? Insbesondere bessere als bei reinem Mesh durch die Luft?
Ich habe hier zwei separate, ähnliche Setups, die beide massive Probleme haben. Es ist das übliche „Offloader“-Konzept:
In beiden ist an einem dicken Router fastd-Uplink an (WDR4900) und an weiteren Routern eben nicht (z.B. 841, CPE, Nanostation). Das funktioniert im einen Fall wunderbar, im anderen (wo sehr viele Clients zu bedienen sind), eher schlecht.
Da Kabel trivial möglich ist, wäre es schön, darüber auch zu meshen.
Also: Mesh-on-LAN am 4900 an, bei den anderen Mesh-on-WAN an, dann von WAN zu LAN Kabel. – Eben nach dieser Anleitung hier.
Ergebnis: Laut Karte perfekter Link (1.000/1.000) und laut batctl wird dieser auch verwendet (Pakete gehen größtenteils drüber), aber Konnektivität massiv gestört!
[Von der Sympton-Beschreibung ähnlich wie hier bei @apo:
und hier:
welche beide auch scheinbar nicht gelöst wurden (in dem Sinne, dass Kabel-Mesh klappt).]
ich hatte ein ähnliches setup.
Hauptfreifunker war ein 1043er mit aktivierten lan ports.
An diesen hingen eine Ubiquiti UniFi, eine Nanostation sowie ein 841er.
Mesh on LAN wurde verwendet, aber die Verbindung war eine Katastrophe.
Abgesehen vom vermehrten Traffic per WLAN (trotz Kabel) war keine Verbindung möglich, so dass ich wieder auf WLAN only bin - so funktioniert es hier zumindest am Besten…
Damit nicht Leute ihr ganzes privates Netz ins Freifunk hängen, nur weil sie einen gelben statt blauen Port verwenden.
Wir machen ja Freifunk nicht Frei-LAN. Die gelben Ports wären höchstens für die Knotenbetreiber selbst und die sollen doch bitte ihre eigene Leitung verwenden ;).
Ist als Sicherheitsmerkmal geplant. Besser es geht gar nicht, als dass es auch noch Schaden anrichtet.
uci set network.client.ifname=‚bat0‘
uci set network.mesh_lan=interface
uci set network.mesh_lan.ifname=„$(cat /lib/gluon/core/sysconfig/lan_ifname)“
uci set network.mesh_lan.mesh=bat0
uci set network.mesh_lan.proto=batadv
uci commit network
/etc/init.d/network restart
Dann kann ich trotzdem keinen Client mehr einstecken. (Es wird keine IP-Adresse mehr zugewiesen).