Das hört sich jetzt aber so an an, als ob Du gar nicht „neuste Technik“ sondern „Technik für neue Domain“ suchst.
(Nein, nicht „Neuste Domain“)
1 Like
Vielleicht sucht er ja „neuste Technik für neue Domain“. Neue Technik und zuverlässig schließt sich ja grundsätzlich nicht aus, aber bei Gluon ist seit v2016.1 die Hölle los.
3 Likes
Ich würde dann vorschlagen, den Thread umzubenennen.
Ansonsten würde ich nämlich wirklich die Babel-Leute aus Frankfurt hier ins boot holen wollen.
Siehe auch
Also schlägst du vor, das Modul
gluon-alfred
Zu entfernen. Und was ist damit?
gluon-mesh-batman-adv-14
Kann man da nicht 15 nehmen? Was ist der Unterschied?
wir benutzen seit unserem Start v15, also wüsste ich nicht was dagegen spricht.
1 Like
Crashanfälligkeit bei >1 CPU fällt mir spontan ein; MTU-Issue ist IIRC Upstream gefixt?
Dennoch würde ich bei einem Neustart auf v15 setzen und hoffen, daß der mit v16 wirklich sauber zusammenspielt — man bedenke, daß v14 inkompatibel zu zukünftigen Versionen ist, dies alte batman-adv-Manko soll(!) ab v15 Geschichte sein. Ansonsten sind die Unterschiede aus meiner Sicht nur die Bugs und daß v14 anfängt zu müffeln, während v15 mit aktuellen Kernels mitkommt.
Gretchenfrage: warum Gluon? Wegen des großen Erfolges und vorhandenen ‚Lösungen‘ für das one-L2-mesh-to-bind-them-all-ist-eigentlich-doch-doof-Thema? http://libre-mesh.org bietet eigentlich, was ‚man braucht‘, L2 für zusammenhängende Bereiche, L3 zum Vernetzen derer. Nur mal als Anregung.
1 Like
du hast dort [vorgeschlagen][1] dies in der site.mk zu ergänzen:
-- Wireless regulatory domain of your community.
regdom = 'DK',
Ist das wirklich gültig? Muss das nicht EU sein?
[1]: update to gluon v2016.2 & cleanup by petabyteboy · Pull Request #11 · Freemesh-Denmark/site-fmdk · GitHub
EU ist nicht gültig, es muss DK sein. Guck mal auf einem beliebigen Router auf „iwinfo mesh0 countrylist“.
Da gibt es DK, nicht aber EU.
Hier hab es auch die Diskussion fastd vs. L2TP. Es wird wohl weiterhin bei fastd bleiben. Das ausschlaggebende Argument: abertausende von MAC-Adressen gänzlich unverschlüsselt durch die Netze großer Provider zu leiten, wo mit Garantie die immer-verschlossenen Räume existieren, halten die meisten hier für arg fahrlässig.
Aber ja, L2TP ist ansonsten viel performanter. Vlt. fährt man am besten mit einem DualStack, bei dem L2TP als Opt-In möglich ist aber mit einem klarem Disclaimer versehen wird das man gut abwägen sollte ob es das wert ist.
Cheers,
Arwed
Eine sehr schöne Gelegenheit, diese schon x-mal gelaufene Diskussion auch in diesen Thread hier zu tragen.
Gibt es irgendwelche neuen Argumente?
Und wenn ja, warum dann nicht in dem Technik- oder Ideologie-Thread?
Abgesehen davon: Weder Fastd, noch L2TP sind „aktuellste Technik“.
Thema verfehlt!
Aktuellste Technik wäre Wiregard! (für die VPN-Tunnel)
1 Like
Sorry, könnt den Beitrag gerne löschen wenn auf die Threads verlinkt wird.
Ich sehe da kein Problem den.
L2TP findet zeitlich gesehen nach fastd Anwendung im Freifunk Umfeld. Man könnte also sagen es ist neuer und „moderner“, damit passt es zum Titel. Alles gut.
Naja, „neuer“ und „moderne“ wäre ein Komparativ, hier geht’s aber um den Superlativ „aktuellste Technik“.
Daher ist L2TP (und fastd) meines Erachtens raus. Schlicht weil Wiregard eindeutig neuer ist als die beiden anderen.
(Was nicht heisst, dass Wiregard mehr leistet oder derzeit besser ist, siehe anderer Thread. Es ist halt noch Entwicklungsarbeit nötig. Und im Sinne eines „Forschungs- und Experimental-Netzwerks“ sicher angeraten. Allein weil dort noch Mitstreitende gesucht werden, die es voran bringen.)
Der Gedanke der hinter diesem Thread steckt ist nicht Machbarkeitsstudien zu generieren, sondern vorhandene Technik für eine neue Community zu nutzen.
Fastd, Batman Alfred und Co. sind ja nun schon einige Zeit im Einsatz und zu hinterfragen ob es nicht mittlerweile andere sinnvollere Techniken gibt.
Hintergrund ist die bereits erfolgte Gründung des Freifunk Ablegers Free Mesh DK im vergangenen Sommer.
Je nach Anwendungsfall „eventuell“, wie schon geschrieben:
[quote=„wusel, post:12, topic:13670“]
Gretchenfrage: warum Gluon? […] http://libre-mesh.org bietet eigentlich, was ‚man braucht‘, L2 für zusammenhängende Bereiche, L3 zum Vernetzen derer. Nur mal als Anregung.[/quote]
Benutzt wird das ja bisher in Spanien (Guifi.net) und Argentinien (Altermundi)
hab ich gerade mal ausprobiert:
- Die leiten anscheinend direkt raus, also kein VPN zum Umgehen der VDS
- Installation schlägt erstmal fehl, weil der dateiname des images der stable version zu lang ist, gekürzt installiert er aber
- habe dann die developer version auf 2 routern installiert
- startet direkt nach dem flashen im betriebsmodus und ist sofort einsatzbereit
- Meshen geht sofort, wenn man sich per kabel an einem maschenden router verbindet ist man auch sofort mit drin
- jeder der damit per wlan verbunden ist, kann sich per konsole direkt auf dem router einwählen per ssh, OHNE PASSWORT!!! was geht hier ab?
- Die Dokumentation ist gerade erst angefangen und enthält noch nichts
soviel der schnelltest dazu.
Scheint mir, da müsste man einiges an der Firmware ändern, damit die über ein gateway rausleiten, das die VDS umgeht, oder?
Hab mal angefragt in IRC channel libremesh auf freenode, da sind ein paar am rum-idlen.
muss ich kurz korrigieren, wireguard is hoch experimentell.
es gab/gibt problme bei Speicherauslesen → aligned memory access …
wireguard braucht einen kernel 4.2++ → ohne den Sprung zu LEDE wird das also nicht kommen, und dann braucht man on top in jedem fall noch l2tpv3 und batman. Ob und wie das dann noch performt kann im moment keiner absehen.
meine Tests hörten jedenfalls mit den erfogversprechenden Durchsatztests von reinem wireguard auf (das is aber eben nur ein Layer 3 tunnelprotokoll)
hätte man auf den von dir verlinkten Seiten auch sehen können.
Das ist ein guter Punkt.
Für die aktuellste Technik sollte man man demnach auch nicht auf OpenWRT bauen, sonder direkt auf LEDE.
dann biste aber erstmal weg von gluon, oder du wartest noch nen halbes jahr … oder so.
LEDE steht ja bei gluon ziemlich oben auf der AGENDA und wird ja stellenweise schon eingepflegt
Ich hoffe darauf, dass der gluon-master nach dem Release von 2016.2.1 auf LEDE umgestellt wird.
Und wenn man wegen Wireguard sowieso einen Haufen Dinge patchen muss, dann wäre das kein so großer Schritt mehr.