Deswegen muss/sollte auf dem „Mesh only“ node MeshVPN aus sein.
Wenn du sie so verschaltest wie von dir beschrieben, wir kein VPN über VPN laufen, da Mesh on LAN hier einfach keinen Traffic ins eigentlich Freifunknetz wirft sondern eh nur Batman spricht. wenn hier allerdings normales Clientlan dranhängt, flattern vorallem Batman Pakete in Batman rum was ziemlich unschön ist… außerdem würde auch noch das von dir beschriebene Szenario stattfinden, dass VPN über das eigentliche FreifunkVPN fließt.
Merke:
Mesh-on-WAN und Mesh-VPN gleichzeitig aktiv ist immer eine hässliche Kombination, die nur unnötig Traffic erzeugt
In dem Fall solltest Du ein Wlan in Deinem „janz weit hinten-Router“ nur anschalten, wenn Du sehr, sehr genau weisst, was Du da tust. (In >95% der Fälle: Wlan abschalten bitte.)
@Sheogorath ja genau … das korrekte setting wäre dann
uplink → 841 mit mesh-vpn und meshonLAN
gelber port 841 → cpe210 in LAN 1 am Adapter mit meshonWAN und OHNE mesh-vpn
es war nur ne klärende nachfrage: man will auf dem CPE verhindern das der den Uplink benutzt um damit Freifunk zu machen (durch freifunk)
(in dem Setting will der Mensch mit dem CPE verhindern das an der doch recht zugänglichen Stelle „irgendwo“ nicht sein privates lan rausfällt)
@adorfer : hab ich jetzt nicht verstanden - was hat das mit dem wlan zu tun, und welches meinst du hier überhaupt ? br-client?
Da ein Bild mehr sagt als 1000 Worte habe ich mich mal dran gesetzt und es aufgemalt
Wichtig ist vorallem die Einstellung auf Node A. Node B und C können da wie man gerade lustig ist angebunden werden.
Wichtig: Bei der Variante von Node B können nur weitere Freifunkknoten per angebunden werden
Bei Variante C stehen die LAN-Ports wie gewohnt auch für Computer, Drucker, Kaffeemaschinen und was man sonst so ins Freifunknetz hängen möchte zur Verfügung. Allerdings können dann hier über die LAN Ports natürlich keine weiteren Freifunkknoten angebunden werden.
Zuletzt noch ein Dank @danielkrah für die Routergrafiken und ein dank @microsoft dafür, dass ich mir irgendwelche dreckigen Visio-Hacks ausdenken durfte um es halbwegs schön hin zu bekommen
Edit: Fehler behoben have fun
PS: die Grafik darf natürlich beliebig weiterverwendet werden
Ich hätte da eine Problemstellung. Dazu beobachte ich diesen Thread
und hoffe auf eine endgültige Erleuchtung… Gerne hätte ich das auch
Visualisiert. Könnte man mir die Grafiken zur Verfügung stellen, dann
mache ich das gerade mal…
Mein Ansatz:
Gemeindezentrum einer Ev. Kirchengemeinde. Dort WR-1043ND am
Kabel. Von dort via WLAN (Funk) auf den Kirchturm. Dort 4x CPE210.
Aktuelle Planung. Oben im Turm einen Switch. Alle vier CPE210 da
dann mit Mesh on LAN. Alle 4 CPE werden im Moment jeweils einzeln
über PoE angefahren, würde aber gerne jeweils zwei CPE über ein
PoE Adapter anfahren. Dazu müssten die Versorgungsspannung
irgendwie durchgeschleift werden, auf den einen LAN Ausgang des
CPE.
@angro … eskommt nun ganz darauf an was du mit „per wlan in den Kirchturm“ meinst.
Idealerweise wäre da ein konventioneller Uplink auf dem NICHT-Freifunk kanal
Nicht-Freifunk Kanal, weil dann mehr Airtime für Freifunk bleibt
konventionell, weils da dann kein Freiunk Grundrauschen foo mit nach oben schickt
da könnte also bspw. irgendein Router sein, der sich seinen Uplink via WLAN von „unten“ holt.
Und dann könnten alle CPE an dem angeschlossen werden (Praktischerweise haben viele Router eben 4*LAN , das geteilte POE würd ich dann streichen weil du sonst den Strom von den einzelnen Uplinks trennen musst, oder auf echte LAN-Uplinks verzichtest)
@fuzzle, @all,
beim durchschleifen des PoE hätte ich daran gedacht, dass das Nutzsignal ja auch über den einen LAN-Port eines CPE weitergegeben wird. So könnte ich Patchkabel aber vor allem auch PoE-Adapter sparen. Der Datendurchsatz würde sich ggf. halbieren, wäre aber bei den zu erwartenden Clients, die paralle im Turm online sein werden, wohl kein Problem.
Das wäre vielleicht auch eine Möglichkeit. Die zu überbrückende Sichtstrecke sind ca. 25m, da kann man auf 5 GHz sicher verzichten, um auch hier Geld zu sparen. Denke, dass es mit zwei WR-843 auf einen anderen als dem FF-Kanal ausreichen sollte. Die sollen dann keinen FF-mesh zulassen.
Hier eine Aufnahme, damit man sich das Ergebnis vorstellen kann.
Ich habe zwei PoE Adapter eingespart und betreibe jeweils zwei
CPE-210 an einem Adapter… Läuft wunderbar und mesht mit der
Stadtbücherei über eine Entfernung von 96m. Beste TQ: 100%
Der 841, den ihr da seht, ist ausschließlich als Download im
Einsatz. Der läuft auf Kanal 13, damit ist die Traffic für Up- und
Download vom „FF-WLAN-Traffic“ HF-mäßig etwas entkoppelt.
(Nachteil: aus unserer Sicht kein Auto-Update möglich)
Hier ein Screenshot, der mir fast die Freundentränen in die
Augen getrieben hat. Die TQ ist aber nicht immer so…
A braucht Mesh-VPN, NICHT Mesh-on-WAN.
B braucht Mesh-on-LAN
Rest Mesh-on-WAN oder Mesh-on-LAN, je nachdem welchen Port man nutzt.
Alternativ würde ich A und B nicht mit einer FF-Firmware betreiben, sondern eine Funkbrücke mit OpenWRT direkt und zwischen A und Internetrouter einen belibigen FF-Router als „Offloader“.
Dank für die Klarstellung. A wird mehr oder weniger als Offloader
eingesetzt. Das ist ein 1043…
Wir haben es hinbekommen und nachdem in der Bücherei ein 841
durch einen 1043 ausgetauscht wurde, auch echt gute TQ-Werte.
(A hängt an 200 MBit und die Bücherei an 50 MBit)
Diese Bandbreite wird natürlich niemals benötigt. Diejenigen, die
ihren Internetanschlüsse teilen, werden daraus aber auch keine
Nachteile zu befürchten haben…
Download?
Du meinst (hauptsächlich) AP für Clients?
Warum soll damit kein Auto-Update möglich sein?
Zu der mechanischen Lösung:
Kabelbinder bitte redundant auslagen, wobei einer immer „nur locker“ sein sollte
Die Tüte aus Schutz gegen den Vogelkot wird nicht lange halten. ich empfehle Dringend eine Lage dickere Teichfolie, wenn ihr das schon so machen möchtet. Wobei ein geschlossenes Gehäuse dort wirklich überflüssig ist. Dreck- und Schutz gegen Tropfwasser reicht vollkommen.
Hier noch eine Aufnahme zur Vervollständigung. Den Schutz
für den Downlink werden wir noch verbessern. Das war eine
„quick and dirty- Lösung“, sodass da wir erst mal schauen
konnten, wie unser Kirchturm überhaupt angenommen wird.
Ich wollte das grade mal austesten und bekomme auf einem 841N mit 2016.1.2 ein „uci: Entry not found“.
Ist das feature erst in neueren Gluon-Versionen implementiert?
Hatte ich coh verlinkt, das ist erst zu 2016.1.4(?) mit hineingekommen.
Daher gibt es das Frankfurter Paket, welches wirkt, wenn man es in die neue FW einbackt, wenn vorher im Router eine „alte Firmware“ drin ist.
have fun
