Jup.
Das mal bitte hier: Issues · oszilloskop/Gluon2Futro · GitHub kund tun.
Nein. Das ist die Batman MTU die muss so klein sein, weil manche Communities (wir auch) eine gesamt mtu von 1280 fahren und nur dann genug Platz für den Rest der Bits im Frame ist.
Nicht böse sein aber das ist beides Gluon foo und hat erstmal nix mit dem Futro zu tun.
So.Wie ich es oben beschrieben habe, geht es also nicht. Nach dem Commit schicke ich den Futro ins Offline Nimmerland. Wie dann?! Kann ja nur noch die Option Mesh VPN weglassen.
Edit: Ach. Oder ist es normal? Der Futro wird erst wiedere zuglänglich, wenn der dann am separaten Freifunk Router via VLAN hängt? Ich dachte, zwecks Überprüfung der Konfiguration würde der sich weiterhin verbinden, wenn er einfach direkt am Heimnetz mit der VLAN Konfiguration hängt.
Ich habe es jetzt zum Laufen bekommen. Da ich beim besten Willen mir nicht mehr vorstellen konnte, dass da bei der Switch Konfiguration am Router noch etwas falsch sein könnte, habe ich mich noch mal mit dem Futro befasst.
Dazu habe ich dann doch mal den Linux PC angeworfen und die zweite Partition von der CF Karte gemountet. Warum auch immer, die Änderung von /etc/config/network/ waren nicht übernommen worden?!
Ich hatte es leider schon befürchtet. Der Speedtest ergibt nur knapp 4MBit/s. Ziehe ich den Futro wärend des Speedtests heraus, so hängt der Speedtest - Futro wird also tatsächlich benutzt. Nur die knapp 4MBit/s habe ich vorher auch ohne Futro erreicht.
Eigentlich sollte der Futro Offloader für 3 noch separate Router werden, da die auch immer nur mit Glück 5 MBit/s erreichen bzw. häufig nur knapp 2 Mbit/s.
Wie war das noch mit dem Futro beim Systemstart? Mein S550 war nach erfolgreichen Nachbauen des FAQ Beispiels 16 knapp eine Woche stromlos. In der Zeit wurden wohl die Bios Einstellungen vergessen. Denn der Futro hing am Start, weil keine Tastatur angeschlossen war. Zudem piept der Futro jetzt 2x kurz, oder hat der das zu Beginn auch schon gemacht?! Wird wohl die CMOS leer sein? Speicher wurde mit Memtest86+ fehlerfrei getestet.
Basierend auf dem FAQ Beispiel möchte ich jetzt an Port 3 des Beispielrouters 2 weitere FFRouter in Reihe anschließen, die momentan noch eigenständig laufen. Dazu muss ich doch bei den zwei weiteren Routern einfach nur per Webinterface Mesh VPN deaktivieren, Mesh On LAN/Mesh on WAN aktivieren? Oder habe ich da etwas vom Prinzip übersehen? Ich frage deshalb, da die weiter angeschlossenen FFRoutern dann ja wahrscheinlich per Defaultkonfiguration von der Nummer her in einem VLAN1 hängen werden und an ein VLAN8 angeschlossen werden. Oder sollte man dann am Router aus dem FAQ Beispiel besser den Port 3 oder 4 zusätzlich untaggen?
Es ist doch richtig, an den angeschlossenen Routern Mesh VPN zu deaktivieren, da die Verschlüsselung ja der Futro machen soll? Denn ich habe z. B. beim Vergleichen auf der Freifunk MAP meines Freifunkgebietes ein Futro Beispiel gefunden, wo alle FFRouter in dem Mesh noch Mesh VPN aktiviert hatten, laut Webinterfaceinfo.
Insofern berechtigte Frage, als ich auch auf geteilte Meinungen zu stossen schien. Ich habe da versucht in den letzten zwei Wochen, da auch auf präzise Formulierungen dritter zu achten. Aber mir reichte das nicht. Evtl ist das community- bzw imageabhaengig. Aber imho sieht es so aus:
Wenn ein Knoten selber keine Route hat, über die er ohne Batman seine Communityserver erreichen könnte, so müsste das Setting MeshVPN irrelevant sein. Dann kann er kein MeshVPN - Punkt.
MeshVPN impliziert ja schon wieder Batman Traffic und den schicke ich ja wohl kaum durch ein Batman gestütztes Mesh zu einem Nachbarn nach draussen, also MeshInMesh quasi.
Zumindest bei meinen Ddorfer Knoten ist das so. Und das war wohl auch so bei dem von Dir erwähnten Bsp.
Es kann umgekehrt natürlich sein, dass man im Netz mehrere Knoten hat, die direkt VPN Server erreichen könnten (uplinkfähig sind sozusagen), aber man will, dass nur einer das macht, nämlich der Offloader oder ein besonders befähigter. Dann muss das Haekchen bei den anderen (uplinkfähigen) weg.
Ich hatte die Futro/FF Router Combi soweit nachgebastelt, wurde dann aber verworfen, wegen des ausgebliebenen Geschwindigkeitsvorteils zu Einzelgeräten in der fastd Community hier.
Ich hatte mich in der Diskussion ja gefragt, wie es sich mit weiteren FF Routern verhält, die man an der Futro/FF Router VLAN Combi per LAN Mesh anschließt. Heute wurde mein WA860v1 im Hausnetzwerk frei. So konnte ich das mal für mich testen.
Also WA860v1 mit FF geflasht, Mesh VPN aus, Mesh on WAN an (hat ja nur die eine Buchse) und am freien gelben LAN Port des anderen Freifunk Routers angeschlossen, an dem der Futro hängt. WLAN ist nur für den WA860v1 aktivert, um Verwechslungen auszuschließen.
Ergebnis: Die Geschichte läuft, ohne beim WA860v1 mit VLANs arbeiten zu müssen.
Aber: Die Geschichte läuft auch, wenn ich den WA860v1 irgendwo anders in das private Heimnetzwerk hänge, gebildet von Powerline Adaptern. Der WA860v1 findet den Futro über das PLC Heimnetz und dann den Internet Uplink der Futro/FF Router Combi, also VLAN7.
Ich frage mich halt, ob das so beabsichtigt ist, ich was falsch konfiguriert habe oder ob umgekehrt auch Freifunk Pakete vom VLAN8 des Freifunk Routers indirekt über den Umweg Futro auch das Heimnetzwerk überfluten könnten?!
Die Fragezeichen und das “können” kannst Du streichen in dem Fall wo Du auf Deinem privaten Netz “Heim-Lan” (aka WAN für den Futro) einen Wireless-AP haben solltest.
(Was die Regel sein dürfte.)
Sprich: mach den Futro nochmal platt und setze ihn neu auf. DAs wird das Schnellste sein.
Bei deiner Konfiguration mescht Freifunk durch dein privates Netz. Das ist in sofern etwas blöd, weil es dein privates WLAN langsam macht, weil alle Meshpakete, das gesamte Grundrauschen durch dein privates WLAN gehen.
Ich gebs auf. Ich habe den Futro und den 740n noch mal neu aufgesetzt. Dennoch bekommt der 860re eine Verbindung übers Uplink VLAN7 des 740n zum Futro, wenn ich den 860re irgendwo ans private LAN anschließe.
Dann hatte ich noch Hoffnung, als das sich die zwei CFG Anleitungen oben für den S550 insofern unterscheiden, als dass für mesh_lan das Attribut proto einmal mit gluon_mesh und einmal mit batadv belegt wird. Macht im Betrieb irgendnwie keinen Unterschied.
Anbei meine /etc/config/network Dateien. Vielleicht kann da jemand einen Fehler erkennen?
Kann man eventuell nach irgendeinen speziellen UDP Port in Wireshark filtern, um auszuschließen, dass der Futro generell immer das mesh_lan ins Heimnetz verteilt, auch wenn sich kein FF Router im Heimnetz befindet?! Irgendwo muss man ja anfangen den Fehler zu suchen, ob das VLAN nicht beim Futro oder 740n klappt.
cnfgs.zip (2,8 KB)
Nachtrag: Mir ist eingefallen, dass es eigentlich auch nicht weiter schlimm ist, wenn es dazu keine Lösung geben sollte. Wird es doch mal zum Einsatz kommen, wird es an eine Fritzbox 7390 angeschlossen Die hat ja LAN4 Gastzugang, so dass das Heimnetz dort keine Probleme bekommen sollte.
Hatte ich mich ja auch mal gefragt, weil es in der OpenWRT Doku zu dem Parameter so steht. Aber das scheint egal zu sein, denn wenn man den Parameter setzt und nicht 0 ist, wird wohl immer ON angenommen, so dass 1 oder 8 keinen Unterschied ausmacht.
Hallo FFer,
ich wollte auch VLAN Offloader mit einem Netzwerkkabel / einem Lan port probieren.
habe die Anleitung im ersten Post probiert, es lief aber erst mit
— Config 841n Router –
config interface 'client’
list ifname 'eth0.7’ – eth0 zu eth0.7
…
Config für den Futuro oder bei mir BananaPI klappt mit der Anleitung oben wunderbar…
siehe: Offloader mit BananaPi & 841n?
Ein speedtest zeigt mir 40mbit mit dem Bananapi erster Gen.
