TP-Link TL-WR1043ND "Spezialconfig"

Community Westerwald
1

Hi zusammen,

habe einen Freifunk Knoten in Betrieb, welcher MOL über eine RiFu sendet (fflm-mue-mzh-vpn).

Dieser ist auf dem Dachboden verbaut um die RiFu auf dem Dach mit MOL zu versorgen.

Ich hatte jetzt die Idee, meine Nachbarschaft mit Freifunk zu versorgen und wollte daher noch 2x CPE210 und 1x NanoStationM2 auf dem Dach montieren um diese nach unten angewinkelt in die Nachbarschaft strahlen zu lassen.

Also die drei Geräte würden mit Stock FW laufen und ich würde über diese dann gerne Client Netz ausstrahlen.
Ich möchte vermeiden noch einen weiteren Freifunk Knoten dafür einzurichten und würde daher an dem 1043 folgende Konfiguration vornehmen:

WAN Port → „Mesh on VPN“
LAN1 → „Mesh on LAN“
LAN2+3+4 → „Client Netz“

Jetzt sind per Default scheinbar zwei VLANs eingerichtet:

network.@switch_vlan[0].vlan=‚1‘
network.@switch_vlan[0].ports=‚0t 1 2 3 4‘

network.@switch_vlan[1].vlan=‚2‘
network.@switch_vlan[1].ports=‚0t 5‘

VLAN 1 = 4x LAN Port (gelb)
VLAN 2 = 1x WAN Port (blau)

Ich denke ich müsste jetzt ein drittes VLAN einrichten und dort die Ports entsprechend zuweisen und dann „irgendwie“ dort das Client Netz drauf konfigurieren.

Hat das schon mal jemand konfiguriert und könnte mir die Arbeit ersparen das selbst zu „basteln“?
Oder ist sowas eigentlich gar nicht denkbar?

Viele Grüße,
Patrik

1 „Gefällt mir“
2

Paste bitte man deine komplette /etc/config/network.

3

Hi,

nette Idee, aber ich sehe da folgendes Problem:
Du würdest über die beiden CPEs und die M2 nur das Client Netz ausstrahlen. Zwar könnten dann deine Nachbarn sich mit ihren Handys oder Computern mit dem Freifunknetz verbinden, aber ein anderer Freifunk Router in deiner Nachbarschaft könnte nicht mehr mit deinen meshen.

Daher würde ich doch die drei Geräte mit unserer Freifunk FW ausstatten, MOL an VPN aus und dann passt das.

4

Das gerät steht in einem anderen Gebäude, muss ich dann bei Gelegenheit mal nachliefern. Ist aber „default“ mit nem Häkchen bei „Mesh on LAN“.

5

Ach quatsch. Ich meinte bei den CPEs und der M2 Mesh on WAN. Sorry

6

Hi, das ist natürlich auch eine Möglichkeit. Allerdings habe ich aufgeschnappt, dass es wohl besser ist die Ubiquiti HW nicht mit Freifunk FW zu betreiben, da es teilweise zu unerwünscht hohen Sendeleistungen kommt?
Und ob es so gut ist, dass da ggf. mehrere Knoten anfangen über WLAN zu meshen? Das ist doch sicherlich deutich langsamer oder?

7

Anders gehts nicht da die config je nach Modell leicht abweicht.

8

Du musst halt aufpassen was du einstellst. Eine Möglichkeit wäre es, den Router mal mit Stockfirmware zu betreiben und dann zu gucken wie weit das Netz reicht. Dann die FF Firmware drauf und dann die Sendeleistung langsam hoch zu drehen und dann wieder gucken. Ich muss sagen, ich hab noch keine Ubiquiti HW mit FF betrieben, aber ich glaube der @justelex hatte da mal was zu erzählt.
Alternativ wäre halt ne dritte CPE denkbar.

Ja, das WLAN Mesh kann durchaus langsam sein. Aber Freifunk ist halt Client und Mesh Netz. Die Idee hinter Freifunk ist ja auch die Vernetzung.

9

Wenn Du das „gut“ ans Laufen bekommen hast, dann dokumentierte bitte das Setup (Wiki Deiner Wahl).
Denn das würde vielen helfen.
(Ich habe mangels Experimentierfreude bislang in den Szenarien immer Geld auf das Problem geworfen und einen kleinen 5-Port-Vlan-Switch hingestellt.)

1 „Gefällt mir“
10

Das Meshnetz ist ein adhoc-Netz und das kann die Originalfirmware nicht.

Was du vor hast, kann die Originalfirmware schlicht nicht. Die beiden von dir genannten Geräte können Gluon, das ist in der Wartung ohnehin einfacher, weil du dich nicht drum kümmern musst. Nur einmal die Sendeleistung korrekt einstellen, dann laufen die Geräte gut mit Gluon.

11

Hi zusammen,

hab folgenden Artikel gefunden, welcher das vorhaben für ein anderes Switchmodell beschreibt.

https://wiki.freifunk.net/Hamburg/router_Schnittstellen#Mesh_auf_einem_LAN_Port_bei_gleichzeitigem_Client-Netz_auf_den_anderen

In Kombination mit den Infos von dieser Seite, habe ich dann eine Konfig gebaut die zu funktionieren scheint.

https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd

Test mit TL-WR1043ND (Version 4.0)

File: /etc/config/network

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0t 1 2 3'

→ Port 4 (entspricht Port 1 gelb) entfernen.

config switch_vlan
    option device 'switch0'
    option vlan '3'
    option ports '0t 4'

→ VLAN 3 anlegen und Port 4 (entspricht Port 1 gelb) hinzufügen.

config interface 'mesh_lan'
    option igmp_snooping '0'
    option ifname 'eth0.3'
    option transitive '1'
    option fixed_mtu '1'
    option proto 'gluon_mesh'
    option type 'bridge'
    option macaddr 'xx:xx:xx:xx:xx:xx'
    option auto '1'

→ Mesh on LAN interface auf das neu definierte VLAN 3 anpassen (aus eth0.1 wird eth0.3) und „option auto“ auf ‚1‘ setzten.

Jetzt hat man Mesh on LAN auf dem gelben LAN Port 1 und auf den gelben LAN Ports 2+3+4 liegt weiterhin das Client Netz an.

Scheint so auch zu funktionieren. Ob die Config „optimal“ ist, weiss ich nicht. Ebenso ist natürlich nicht sicher, ob es das nächste Update überlebt.

Ich wollte es einfach mal testen, um zu sehen ob sowas geht. Ob ich das jetzt so umsetze oder doch lieber Gluon auf die CPEs spiele, muss ich mir noch überlegen.

Viele Grüße,
Patrik

3 „Gefällt mir“
12

Das ist eine Idee, die es schon recht lange gibt. Auch wurde mal darüber gesprochen, ob man dafür ein grafisches Konfigurationspaket bauen könnte.

Das würde vermutlich sofort angenommen. Es müsste nur jemand bauen. :).

Danke für den Beitrag, ich baue da auch gerade an was, einen 1043er als VLAN-Switch zu verwenden. So, wie du es gemacht hast, hatte ich es auch verstanden. Das ‚T‘ steht für tagged.

Grüße
Matthias

2 „Gefällt mir“
13

Naja, ist ja schon nen Sonderfall und vielleicht ist es besser, dass man das nicht grafisch einstellen kann, damit man sich damit auch etwas auseinandersetzt und nicht einfach nur klicken muss :wink:

Für einen 1043 Version 3.0 sieht das Ganze aber scheinbar schon wieder etwas anders aus, wenn ich das richtig sehe. Da müsste ich mir nochmal ein Gerät zum testen holen.

1 „Gefällt mir“
14

Deine Anleitung funktioniert bei mir, vielen Dank!

Ein /etc/init.d/network restart hat mir das Gerät leider abgeschossen. Nach einem Neustart ging es wieder. Wenn man das per Fernwartung macht also lieber drei mal gucken, dass die Syntax passt und dann reboot machen.

15

Ich nehme alles zurück, wenn man auf die LAN-Ports Clientnetz untagged und Meshnetz auf VLAN3 schaltet, hängt sich der 1043er alle paar Stunden weg und ist auch über WAN nicht mehr erreichbar, vermutlich, weil der Switch irgendwie abgeschmiert ist.

Wir probieren jetzt mit einem zweiten Kabel auf einem Port LAN und auf einem anderen Mesh. Mal sehen, ob das stabil läuft.

16

@MPW gut zu wissen, muss bei „meinem“ 100xWLAN-Standort ja auch eine VLAN-Config mit dem 1043er einrichten. Kannst du noch einen Bugreport aufmachen? Damit andere Bescheid wissen und das evtl. gefixt werden kann.

17

Ich hatte mich in Oldenburg noch mit Elektra über die Switche in diesen Billigroutern unterhalten, die sind wohl ziemlich schlecht dokumentiert. Und das ist ja nichtmals eine offiziell unterstütze Funktion. Ich weiß nicht, wo ich da einen Bug aufmachen soll. Meinst du im Gluon oder bei Lede?

Erstmal müsste man an einen eine serielle Konsole anstecken und gucken. Oder per WLAN könnte auch gehen, da kam ich in diesem Fall nicht dran.

18

Habe mal nachgefragt, Bugreport ist sinnvoll. Bei LEDE dann :slight_smile:

19

Okay, danke.

20

hi

wir liefern unsere Firmware standartmäßig so aus das:
WAN → WAN (ethx.2)
2 LAN Ports neben den WAN → Batman/mesh (ethx.3)
2 LAN Ports die weiter weg von WAN sind → Client (ethx.1)

dabei haben wir keine Probleme mit abstürze, das klappt auch auf den 841er und anderen Kisten problemlos.

Für RF Strecken hab ich auf einen 1043er (v2 oder v3 grad nicht ganz sicher) folgende Sonderconfig (hat sich zig mal geändert, deshalb auch weit weg von unseren Standart, hat sich halt so ergeben nach und nach):

CLIENT_PORTS=„1 2 4 6t“ # eth0.1
WAN_PORTS=„5 6t“ # eth0.2 aktuell der einzig freie Port, nicht in Verwendung
BATMAN_PORTS=„3 4t 6t“ #eth0.3
plus ein weiteres VLAN um Babel von einer auf ne andere RF Strecke umzusetzen (eigentlich ist 6t unnötig aber egal):
config interface ‚vlan4‘
option ifname ‚eth0.4‘
…
config switch_vlan ‚eth0_4‘
option device ‚ag71xx-mdio.0‘
option vlan ‚4‘
option ports ‚1t 4t 6t‘
(6t ist zur CPU)

Plan sieht noch vor, 4t mit ins eth0.2 zu stecken, damit das priv. Netz über die RF Strecke hier wieder auf den blauen Port untagged mit rausfällt, wird demnächst konfiguriert und klappt bestimmt auch :wink:

läuft noch unter dem letzten OpenWRT Release, würde aber wetten das klappt unter LEDE genauso. Kein Gluon sondern eigene Firmware.

auch dieser läuft absolut stabil ohne Probleme. Nur 841er mögen es nicht, auf einen Port tagged und untagged gleichzeitig, sie taggen dann einfach alles obwohl die config was anderes sagt (ihhhh). Hab auch mal was munkeln hören das VLAN IDs >16 Probleme machen sollen, hab ich bisher aber nie gebraucht und zumindest ein Kollege hat auf nen wdr4900 VLAN ID 101 am laufen, also entweder betrifft das nur einen Teil der Router oder ist nur ein munkeln :wink:

Also entweder ist es ein Gluonspezifsches Problem oder… Wobei ich mir nicht vorstellen kann, was Gluon da kaputt machen sollte. Am Switch der Router scheint es auf jeden Fall nicht zu liegen.

Achja bei den ganzen Sonderconfig Zeug muss man höllisch aufpassen, das man keine 2 gleichen MAC Adressen ins gleiche Layer 2/Batman Netz steckt!

mfg

Christian