TP-Link CPE210/510

Technik Hardware
90

[quote=„adorfer, post:89, topic:594“]
Ist das bestätigt? Zumindest war ich bislang davon ausgegangen, dass dort „nur“ geswitched das WAN (also die erste Buchse) ansteht.[/quote]
Ich ging auch davon aus, das der WAN einfach weitergereicht wird. Welche Interface-Daten brauchst du? Kann gerne nachschauen.

[quote=„adorfer, post:89, topic:594“]
Wenn nicht, dann sollte meiner Meinung nach geändert werden im Gluon, weil es schlicht anders keinen Sinn ergibt. (Sofern nicht jemand eine Überwachungskamera in Mastmontage ins Freifunk-Netz hängen will auf dieser Weise. Dürfte aber nicht so die Standard-Anwendung sein im Vergleich zu „Zwei Freiunk-Router an einem Mast“)[/quote]
Genau so sehe ich das auch. Damit wäre mein Problem auch schon sofort erledigt.

91

mach doch mal nen pastebin von ‚uci show network‘

92 
# brctl show
bridge name     bridge id               STP enabled     interfaces
br-client       7fff.e8de27cebdd4       no              eth0.2
                                                        bat0
                                                        wlan0-1
br-wan          7fff.eadf27cebdd4       no              eth0.1



# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 2
        link: port:4 link:down
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3
VLAN 1:
        vid: 1
        ports: 0t 5
VLAN 2:
        vid: 2
        ports: 0t 4

Am zweiten Port ist hier nichts angeschlossen, deshalb „Port 4 down“

93

Was wieder bedeutet, das im Expert Modus am besten eine Switch Konfiguration eingebaut werden sollte um bei diesen Geräten wählen zu können ob der Anschluss mit WAN gebridged werden soll oder nicht.

94

Bitteschön: http://pastebin.com/0EnA2kNf

95

Meiner Meinung nach (und den Unfällen der letzten Wochen, siehe auch aktuellen Störungsthread Ruhrgebiet und dem letzten im Rheinufer) sollte „BRclient“ an den LAN-Buchsen per Default AUS gestellt werden und nur unter irgendeinem kryptischen Namen in der Expert-Config erreichbar sein. An ALLEN Freifunk-Routern.

3 „Gefällt mir“
96

Hier noch meine Ausgaben von brctl und swconfig:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-client       7fff.14cc204744ea       no              bat0
                                                        wlan0-1
br-wan          7fff.16cd204744ea       no              eth0.1
 
# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 2
        link: port:4 link:up speed:100baseT full-duplex auto
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3 
VLAN 1:
        vid: 1
        ports: 0t 5 
VLAN 2:
        vid: 2
        ports: 0t 4

EDIT: Bei mir fehlt wohl die Brücke zu eth0.2, weil ich mit Mesh-on-LAN rumexperimentiert hatte.
97

Da stimme ich zu. Der Schaden überwiegt den Nutzen momentan.

Eine Auswahlmöglichkeit in der Config sollte die Poweruser zufrieden stellen.

2 „Gefällt mir“
98

So, ich habe den Vorschlag von @Freigraf jetzt mal ausprobiert. Aktuell sieht es so aus:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-wan          7fff.16cd204744ea       no              eth0.1
                                                        eth0.2
br-client       7fff.14cc204744ea       no              bat0
                                                        wlan0-1

# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        pvid: 0
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
        pvid: 0
        link: port:1 link:down
Port 2:
        pvid: 0
        link: port:2 link:down
Port 3:
        pvid: 0
        link: port:3 link:down
Port 4:
        pvid: 1
        link: port:4 link:up speed:100baseT full-duplex auto
Port 5:
        pvid: 1
        link: port:5 link:up speed:100baseT full-duplex auto
VLAN 0:
        vid: 0
        ports: 0t 1 2 3 
VLAN 1:
        vid: 1
        ports: 0t 4 5 
VLAN 2:
        vid: 2
        ports: 0t

Sieht also genauso aus, wie gedacht. Allerdings funktioniert es nicht. Sprich: CPE #2 erhält keine IP-Adresse und mesht weiterhin über WLAN.

Was mich doch etwas verwundert: VLAN 2 hatte ich über die uci Kommandos gelöscht, aber es taucht trotzdem noch auf?

Jemand noch eine Idee?

99

Am VLAN 2 ist nur noch Port 0 verbunden, das ist der virtuelle Port der CPU.

100

Ok, ich habs endlich hinbekommen :grinning:

Der Grund warum es nicht geklappt hat:

Ich hatte eth0.2 in die Brücke br-wan getan. Mir war nicht bewusst, das eth0.1 und eth0.2 keine echten Interfaces sind, sondern nur VLANs. eth0.1 ist VLAN1 und eth0.2 VLAN 2. Damit habe ich beide VLANs zusammengebrückt, was natürlich absoluter Käse war :smile:

Hier die nötigen Schritte, um das Netz am WAN-Port eines CPE210 an dessen Secondary LAN-Port weiter zu reichen. Der an den Secondary LAN-Port angeschlossene, zweite CPE210 nutzt dann den gleichen Uplink und bekommt eine eigene IP-Adresse vom Router/Modem zugeteilt und kann sich somit auch seinen eigenen VPN-Uplink zu einem Supernode aufbauen:

# eth0.2 aus dem Client Netz nehmen
uci set network.client.ifname='bat0'

# VLAN 2 löschen
uci delete network.@switch_vlan[1]

# VLAN 1 den freigegeben Port 4 (LAN) zuweisen
uci set network.@switch_vlan[0].ports='0t 4 5'

uci commit network
/etc/init.d/network restart

Danke auf jeden Fall an @Freigraf für den entscheidenden Tipp!

3 „Gefällt mir“
101

Nötig für was jetzt GENAU?
Will sagen: Posting bitte „im ganzen Satz“, damit sich spätere LeserInnen das nicht im Thread zusammensuchen müssen.
Was bezwecken obige Befehle? Schreib es bitte in das Posting selbst. Danke.

102

Habs gerade ergänzt.

2 „Gefällt mir“
103

Könnte bitte $jemand die Erkenntnisse vom @fux in die Gluon Dokumentation einpflegen? Vielleicht der @tcatm?
Also da: Commandline administration · freifunk-gluon/gluon Wiki · GitHub

104

Die Erkenntnisse sind bereits im richtigen Ort gelandet. Der nächste Schritt wäre daraus ein OpenWRT Paket zu erstellen, das PoE-Passthrough per UCI Option aktivieren kann, eines das den Wert aus der site.conf setzen kann und eines, das dem User das Aktivieren im Expertmode ermöglicht.

1 „Gefällt mir“
105

http://wiki.freifunk.net/konsole
Hier kann es jeder nachpflegen…

106

Darum ging es ja hier nicht, sondern um „WAN statt br-client am zweiten Port“.

107

Achso. Es geht darum auf dem zweiten Port zu meshen? Das ist mit Mesh-on-LAN auch schon abgedeckt und wird hoffentlich mit Gluon 2015.1 direkt in der Firmware konfigurierbar werden.

108

Nein. Leider auch falsch.
Es geht darum, WAN von Port 1 auf Port 2 zu bringen (und auf ein eth-brclient zu verzichten)

Zumindest verstehe ich die Einleitung da oben so.
TP-Link CPE210/510 - #100 von fux

109

Das erspart unterm Strich ein weiteres Netzteil mit extra Lankabel. Dies kann bei einer Mast/Balkon-Montage durchaus sinnvoll sein, vor allem bei hohem Clientaufkommen und entsprechendem Traffic und bietet 2 dedizierte Uplinks mit entsprechender Uplink-Bandbreite.