Site.conf mit aktuellster Technik für neue Domain

Wenn man eine neue Community gründet, welches wäre dann die neueste Technik?

Ich denke man sollte gleich mit 802.11s starten statt ad-hoc und für den Alfred gibt es doch inzwischen auch eine alternative. Und fastd oder l2p?

Gibt es eine site.conf und site.mk, die da empfohlen wäre?

Du fragst nach „neuster Technik“:
Wenn es darum geht: Freifunk-FFM hat ein Babel-Gluon, welches ohne Batman auskommt und daher auch in großen Domains skalieren soll.

(Du hast nicht nach „zuverlässig“ oder „erprobt“ gefragt)

2 „Gefällt mir“

11s und respondd (am Server dann eben hopglass-server und hopglass statt alfred-master und meshviewer)
Das ist aber nichts ganz so neues, es gibt schon diverse Communities die migriert haben und das schon nutzen.

fastd vs. l2tp ist meines Erachtens keine Frage der neuesten Technik, sondern teils ideologisch.
Da sich noch keiner um eine gluon-upstream-Integration der l2tp-Variante gekümmert hat, würde ich allein schon aus Wartungsgründen fastd vorziehen.
l2tp erlaubt zudem keine Verschlüsselung, muss man abwägen ob dies gewollt ist. (Ja, ich weiß dass die Luftschnittstelle ja auch nicht verschlüsselt ist, aber darum geht es hier nicht!)

1 „Gefällt mir“

Da kann ich mich nur anschließen.
Respondd, 11s und L2TP sind in vielen Communites schon mehr als ein Jahr „stable“.
Wenn man „neuste Technik“ sucht, dann sollte man darum einen Bogen machen.

Ja zuverlässig sollte es schon sein. Geht um Freemesh Denmark.
11s ist schon aktiv. Was muss ich denn an unserer site ändern, damit respondd, und die jeweils neuesten Versionen von fastd und Batman genommen werden?

site: GitHub - Freemesh-Denmark/site-fmdk: These are the config files for Freemesh Denmark, a Gluon mesh network.

(gerne ein PR)

@rubo77 PR ist raus.

2 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 · 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 „Gefällt mir“

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.