weiß jemand, wie man das WAN auf einer 4040 als zusätzliches VLAN (z. B. 10) auf einem der gelben Ports ausgibt?
Anwendungsfall hier ist, dass an der 4040 proprietäre APs hängen, die untaggt mit Freifunk-Clientnetz und taggt mit dem WAN-Netz versorgt werden sollen.
Auf den 1043ern kann man einfach in der /etc/config/network beim VLAN-Block 2 den LAN-Port hinzufügen.
Und auch die 4040 zeigt an, dass intern so gearbeitet wird:
Aber das VLAN 2 taucht in der /etc/config/network nirgendwo auf. Ich hatte jetzt überlegt ob man ein weiteres Interface in br-wan hängt, aber ideal ist das nicht, weil dann alles durch die CPU muss statt auf Hardwareebene geswitcht zu werden.
Ich würde dir abraten id 2 zu benutzen, da irgedwas manchmal „hard-wired“ ist. Ensprechend kannst du auch mit der swconfig die ports abändern. Wichtig ist nur das alles tagged zum cpu port ist (nehme ich mal an).
Deswegen mach doch so? Dann ist dhcp einfach untagged auf allen ports.
danke für die Antwort. Wenn ich sie richtig verstehe, beziehst du dich hier aber nur auf die gelben Ports. Ich suche eine Lösung für den blauen Port, bzw. möchte den blauen Port auf die gelben durchbridgen.
Ich hab’s gelöst, es ist tatsächlich so trivial. Einfach unter dem VLAN 1 einen Block für wie oben richtig geraten VLAN2 anlegen. Obwohl es standardmäßig nicht drin ist, geht es genau wie bei einem 1043er.
Jedoch konnte ich die IP der 4040 auf dem WAN-Port nicht von einem Gerät am gelben Port aus erreichen. Von Upstream aus ging es und die durchgebridgten Clients konnten auch Upstream alles erreichen. Für meinen Anwendungsfall genügt das erstmal. Der Switch in der 4040 scheint nicht zu checken, welche MAC die CPU im Gerät selbst hat.
Ich würde dir trotzdem dazu raten, beide ports zu taggen zur CPU hin und nicht dieses vlan2 bzw 1 zu benutzen. Port 5 ist das WAN. Aber wenn es läuft, dann lass es so.
hab mir das Ticket mal durchgelesen. Ich würde erstmal beobachten, ob das jetzt auftritt.
Wir haben viele 4040 mit VLAN-Konfig im Einsatz. Häufig einfach Mesch und Clientnetz parallel auf einem Port um über einen Switch Außenrouter mit Mesch- und Innenrouter mit Clientnetz zu versorgen. Da hat es noch keinen einzigen Absturz gegeben, soweit mir bekannt ist.
Und jetzt eben die Konfig mit dem WAN-Netz. Bisher auch keine Probleme.
Werde das auf jeden Fall mal beobachten.
4040 hab ich noch einige hier. Hast du einen konkreten Test, den ich nachstellen soll? Dort wirkt es einfach so, als ob die Geräte sich halt weghängen, was ich bei mehreren Geräten, teilweise schon Monate im Einsatz, bisher nicht hatte. Allerdings mit Gluon, nicht mit OpenWrt.
Ne, aber mittlerweile hat @blocktrron glaube ich auch einmal den Crash Reproduziert. Und es ist wirklich so merkwürdig. Ich glaube mit unterschiedlich viel Traffic trittt auch der freeze unterschiedlich oft auf. Ich wollte mal nen iperf3 testbed aufbauen.
Hier nur der Hinweis für alle, die den Thread ab 2022 lesen:
Gluon 2022.1 unterstützt VLANs jetzt updatefest.
Wer mag kann sich ja mal die Doku ansehen, die wir dafür gerade vorbereiten, ob es noch Verständnisprobleme gibt:
@MPW wenn ich das richtig im Kopf habe, wird es nicht möglich sein Client und Mesh auf dem selben Interface gleichzeitig zu betreiben, weil das zu Schleifen führen kann, die Gluon nicht abfängt.
Den Satz verstehe ich nicht. Es geht gerade um VLANs, also das Trennen von virtuellen und physikalischen Interfaces. Schleifen machen in Mesh nichts um im Clientnetz darf das sowieso nicht sein. Und ehrlich gesagt verstehe ich deinen Satz auch nach mehrfachem Lesen nicht.
Mein Fehler. Die Info, dass du zwei getrennte VLANs auf dem Interface für die beiden Rollen nutzt hatte ich überlesen. Das geht natürlich weiterhing aber jetzt persistent konfigurierbar und von gluon unterstützt
Ich hatte rausgelesen, dass du auf dem selben VLAN-Interface Mesh und Client gleichzeitig abgeworfen hättest und das keine Probleme verursacht hätte.