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.
Habs gerade ergänzt.
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
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.
http://wiki.freifunk.net/konsole
Hier kann es jeder nachpflegen…
Darum ging es ja hier nicht, sondern um „WAN statt br-client am zweiten Port“.
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.
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
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.
Das hast du richtig verstanden
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?
[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
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.
[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.
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.
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?
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.
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
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)
Was sehe ich denn da?