ich habe gestern zwei Freifunk Knoten in Betrieb genommen. Gedacht war die Konfiguration so, dass ich die PicoStation M2HP für den Ausseneinsatz nutze und diese an einen freien LAN Port vom TL WR842N hänge.
Die beiden Router laufen auch, werden auch auf der Karte angezeigt, aber laut Status läuft das Mesh nur über WLAN.
Wenn ich mich mit meinem Notebook an einen freien LAN Port vom TPLink hänge, bekomme ich auch keine IP aus dem Freifunk Netz, daher vermute ich dass WAN und LAN im Router nicht gebridget sind. Kann mir jemand sagen wie ich das ändere?
Macht es überhaupt sinn das WLAN vom TPlink eingeschaltet zu lassen? Er soll ja nur im Hintergrund das Meshing via VPN steuern da die Picostation dafür etwas zu schwach ist. Beide Router stehen aber unmittelbar hintereinander?! Wie ist da eure Erfahrung?
Auf den Lan Ports des TP-Link muss in dieser angeschlossenen Konstellation batman aktiviert werden, in den Pico-Stations muss Mesh on Wan aktiviert werden.
Per SSH Mesh on Lan im TP-Link aktivieren:
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
Per SSH in den Picostations dann VPN deaktivieren und Mesh on Wan aktivieren:
uci set fastd.mesh_vpn.enabled=0
uci set network.mesh_wan.auto=1
uci commit
reboot
Testen ob es dann hoch kommt, wenn nicht den TP-Link auch nochmal rebooten. Wenn es dann immer noch nicht funzt nochmal melden.
Wo sehe ich denn ob die Picostation via LAN meshed? Die Config hatte ich sogar vorher schon so eingerichtet, aber in dem jeweiligen Status der Nodes sehe ich unter Neighbours nur Station XY (on WLAN0).
Oder muss ich das Meshing für WLAN explizit unterbinden?
Ein ähnliches Setup wollte ich mit einer Nanostation M2 demnächst auch aufsetzen (noch ist sie nicht angekommen ;)).
Dass am anderen Knoten (hier dem TP-Link) Mesh-on-LAN aktiviert werden muss, habe ich mir schon gedacht, ging aber aus den verschiedenen Dokus, die ich gefunden habe, nicht so klar hervor: https://wiki.freifunk-rheinland.net/Nanostations#Mesh_on_WAN
Vielleicht sollte jemand™ das ausführlicher beschreiben?
(Wenn ich es selbst probiert habe, würde ich das ja auch nach der „Sei mutig!“-Wiki-Philosophie tun, aber nach drei Tagen Freifunk möchte ich die Wikis dann doch noch nicht mit meinem Halbwissen verunreinigen. ;))
Du wirfst glaube ich Mesh-VPN, Mesh-on-WAN und Mesh-on-LAN durcheinander.
Mesh-VPN: Ich leiste Verschlüsselungsarbeit und baue eine Verbindung zum Supernode auf. Möglicherweise bin ich der stärkste lokale Knoten (z.B. 1043)
Mesh-on-WAN: Ich meshe via Kabel mit Knoten deren WAN-Port am selben Switch hängen wie mein WAN-Port und die ebenfalls Mesh-on-WAN aktiviert haben.
Mesh-on-LAN: Aus gewissen Gründen (Switch sparen oder so) möchte mein Besitzer, dass ich via LAN meshe. Deshalb mache ich das jetzt und beim nächsten Autoupdate ärgere ich ihn und gebe am LAN-Port wieder das Client-LAN (wie das „Freifunk“-WLAN) aus
Bei mehreren verbauten Knoten ist es sinnvoll nur beim stärksten Mesh-VPN zu aktivieren und die anderen via Mesh-on-WAN anzuschließen. Also du nutzt z.B. einen 1043 als Uplink (mit Mesh-VPN), dort aktiviert du auch Mesh-on-WAN. Bei allen weiteren Knoten z.B. Nanostations schaltet du Mesh-VPN aus, Mesh-on-WAN an und schließt sie an den selben Switch an wie den WAN-Port des 1043.
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…