TP-Link CPE210/510

adorfer · 25. Februar 2015 um 12:46

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.

fux · 25. Februar 2015 um 12:49

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.

apo · 25. Februar 2015 um 14:27

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

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

fux · 26. Februar 2015 um 11:08

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?

Freigraf · 26. Februar 2015 um 12:46

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

fux · 26. Februar 2015 um 14:04

Ok, ich habs endlich hinbekommen

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

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!

adorfer · 26. Februar 2015 um 15:08

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.

fux · 26. Februar 2015 um 15:29

Habs gerade ergänzt.

Freigraf · 26. Februar 2015 um 21:56

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

tcatm · 27. Februar 2015 um 02:54

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.

gomaaz · 27. Februar 2015 um 07:18

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

adorfer · 27. Februar 2015 um 09:03

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

tcatm · 28. Februar 2015 um 02:20

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.

adorfer · 28. Februar 2015 um 03:49

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

ffkaNordwest01 · 28. Februar 2015 um 12:14

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.

fux · 28. Februar 2015 um 12:25

Das hast du richtig verstanden

adorfer · 2. März 2015 um 13:41

Der Punkt ist ja nicht, „VPN-Uplink für jede CPE“, sondern „Mesh on Wan für eine Dachinstallation ohne Outdoor-Switch“

natürlich kann man auch „mesh on wan + mesh on lan gleichzeitig“ plus „kein brclient-auf lan“ machen.

Nur dann ist es -meiner Meinung nach einfacher- „WAN/softbridge auf beiden Ports“ zu machen, oder?

fux · 2. März 2015 um 14:56

[quote=„adorfer, post:111, topic:594, full:true“]
Der Punkt ist ja nicht, „VPN-Uplink für jede CPE“, sondern „Mesh on Wan für eine Dachinstallation ohne Outdoor-Switch“[/quote]
Doch, genau das war der Punkt in meinem Setup. Ich wollte den zweiten Port am ersten CPE einfach als Switch nutzen, damit der zweite, kaskadierte CPE einen eigenen Uplink/VPN-Uplink bekommt.

[quote=„adorfer, post:111, topic:594, full:true“]
natürlich kann man auch „mesh on wan + mesh on lan gleichzeitig“ plus „kein brclient-auf lan“ machen.

Nur dann ist es -meiner Meinung nach einfacher- „WAN/softbridge auf beiden Ports“ zu machen, oder?[/quote]
Mesh-on-WAN/LAN ist nicht relevant für mich. Ich habe zwar inzwischen Mesh-on-WAN zugunsten der Airtime aktiviert, aber das hat mit dem ursprünglichen Problem nichts zu tun.

EDIT: Aber ich wiederhole mich und wir drehen uns im Kreis. Ich denke es sollte inzwischen klar geworden sein, worum es mir ging

adorfer · 2. März 2015 um 15:19

Ich habe es so verstanden, als ob das politisch(?) unerwünscht wäre, „wegen Traffic-Grundlast auf den Supernodes“, die mit der Anzahl der VPN-Meshlinks schneller steigt als bei reinen „Mesh-On-Wan“-Links.

Anyway: Ziel „WAN auf beiden Ethernets“ möchten wir beide. Dazu „Spannung auf zweitem Ethnernet“.
per site.conf nach möglichkeit, ohne extra-Gluon-Paket.

fux · 2. März 2015 um 15:39

[quote=„adorfer, post:113, topic:594“]
Ich habe es so verstanden, als ob das politisch(?) unerwünscht wäre, „wegen Traffic-Grundlast auf den Supernodes“, die mit der Anzahl der VPN-Meshlinks schneller steigt als bei reinen „Mesh-On-Wan“-Links.[/quote]
Nö. Darüber beschwert hat sich eigentlich nur @DerTrickreiche. In meiner Community gibt es aktuell zwei Supernodes, die beide ca. 50 Nodes versorgen. Da ist das definitiv noch kein Kapazitätsproblem.

Und die beiden Nodes die ich in dem Setup jetzt betreibe, versorgen DEN zentralen Platz in Karlsruhe. Ich gehe davon aus, das wir im Sommer pro Node um die 30-50 aktive Clients haben werden. Da bin ich über den getrennten Uplink echt super froh

Kann man in der Community-Config modellspezifische Optionen setzen? Damit habe ich mich noch nicht beschäftigt.