TP-Link CPE210/510


#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.


#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.


#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


#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.


#110

Das hast du richtig verstanden :smile:


#111

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?


#112

[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 :slight_smile:


#113

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.


#114

[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 :wink:

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


#115

Nö, ich hab mich nicht beschwert, aber ich hatte diesen Schluß gezogen, da ja immer wieder berichtet wurde, daß die vielen VPNs die Supernodes ins schwitzen bringen.

Der Sinn von mehreren verbundenen Nodes mit multiplen VPNs erschliest sich mir dennoch nicht.


#116

Dann versuch ichs eben nochmal zu erklären:

Wenn ich den zweiten Node über Mesh on WAN/LAN anbinde, müssen sich beide die ~12 Mbit, die die Hardware über das VPN schafft, teilen. Wenn jedoch jeder Node selber unabhängig angebunden ist, steht für jeden der beiden Nodes die volle Bandbreite zur Verfügung (Also zusammen ~25 Mbit).

Ist es jetzt klar?


#117

Noch drastischer wird es, wenn ein Node der Wolke einen 200MBit/s-Anschluss hat (die da auch real verfügbar sind), der die aber einfach nicht auf die Straße bekommt… und drei Hops weiter die Leute über die “Freifunk-Last” auf ihrem DSL6000 klagen, weil es ihnen den Upstream zuzieht.


#118

Genau.

Die beiden CPEs habe ich über eine 100 Mbit Leitung angebunden. Die ist damit natürlich nicht nur ansatzweise ausgelastet. Den Upstream habe ich allerdings begrenzt, damit der Anschlussinhaber von seinen 5 Mbit Upstream noch etwas übrig hat :wink:


#119

Wer eine mobile Steckdose unterwegs braucht, um einen CPExx0 Aufstellort zu testen:

…funktioniert für einige Stunden, in diesem Setup ~8-10 Std (je nach Kapazität wunderbar).

x* 3S beliebige Ampereleistung (hier 5Ah) Lipos
1* Spannungswandler 12V => 230V
Ich nutze hier noch ein Wattmeter um den Strom zu messen, ggf einen Lipo-Warner dran, um ein Tiefentladen der Lipos zu vermeiden.
(Primär ein Tip an die Modellbauer, die üblicherweise ältere Lipos für solche Basteleien nehmen)


#120

Was sehe ich denn da? :wink: