Hallo Dezentral, Am Fri, Jun 05, 2026 at 07:19:31AM +0200 schrieb Dezentral via WLANtalk:
Guten Morgen Christof, verstehe ich es richtig, dass der Schwachpunkt darin besteht das zuviele Routing-Regeln entstehen (können), wsl. pro IP im Mesh mindestens eine? Prinzipiell hatte ich auch überlegt Mit ca. wieviel Knoten und Clients im Netz habt Ihr das seinerzeit betrieben? Überlege, ob konkrete technische Diskussionen in eigene Threads auf der WLANware-ML überführt werden sollten, bevor es hier unübersichtlich wird. Soll ich da mal einen Thread eröffnen?
Es gibt zwei Ebenen: Technisch: Wir haben das Netzmodell mit realer Hardware auf 50 Nodes mit 1000 clients ausprobiert. Das ist an einem (mittlerweile behobenen) Bug kaputt gegangen. Ein weiteres größeresExperiment ist mir nicht bekannt. Virtuell hatten wir Netze mit mehreren hundert Nodes. Dave hatte in der Zeit Tests mit sehr vielen virtuellen babel-basierten nodes durchgeführt und auch mit großen Routingtabellen. Dabei hatte er die verfügbare Bandbreite und auch transmission-Probleme zwischen den Nodes mitsimuliert. Wir wissen also, dass es geht und gut skaliert.
Wir wissen auch, dass große Routingtabellen gut funktionieren - sehr viel mehr Installationen nutzen den Linux IP Stack und Routing als L2 Mesh-Netzwerke. Wir wissen auch, dass es auch hier eine Skalierungsbremse gibt: die verfügbare Bandbreite. Sobald also die durch das Routingprotokoll auszutauschenden Daten so groß sind, dass die (dann zu kleine) verfügbare Bandbreite bewirkt, dass Updates sehr spät kommen, dann fällt das Netz auseinander, weil Positionsveränderungen der Endgeräte nicht mehr korrekt weitergegeben werden. Das ist an sich zunächst OK - und eine Eigenschaft aller Mesh-Protokolle, also derzeit ein theoretisches Limit. Gleichwohl: Sobald diese Grenze erreicht ist, gibt es keinen Weg für eine Reparatur. Wenn wir also jetzt eine gute Idee haben, wie man das Netz anders organisieren kann, die uns diese Grenze weiterwegschiebt, dann sollten wir sie untersuchen. Klassische Netze lösen das über mehr oder weniger automatische Segmentierung. Beim Routing durch zusammenfassen von Routen. Der Ansatz in Batman-Netzen ist das Filtern von bestimmtem Traffic an VPN-Grenzen und die manuelle Aufteilung in Hoods.
Jan hatte seinerzeit Ideen, wie man mehrere Mesh-Protokolle auf einen Node bringen kann und lokal Batman spricht, den Netz-Zusammenhalt via routing löst. Das konnten wir In 2019 nicht in 4MB flash auf den TL-WR841 umsetzen. Außerdem gab es Bedenken hinsichtlich der Komplexität der Unterstützung von mehreren Protokollen in Gluon gleichzeitig. Jetzt stehen wir an einem anderen Punkt, der uns in dieser Frage neuen Spielraum verschaffen dürfte.
Organisatorisch: Die Babel-Umsetzung in Gluon war von Anfang an als Proof of Concept gedacht. Ich wollte zeigen, dass Roaming in Netzen mit L3 routing geht und viele haben mitgeholfen. Wenn ich jetzt an diese Zeit zurückdenke, waren es mehr als7 Personen und wir standen nicht bei Null, sondern es gab bereits Konzept.
Dieser technische POC war aus meiner Sicht erfolgreich. Wir wollten teilweise zu viel (z.b. haben wir damals wireguard als Teildes Routings mit umgesetzt und es ist gut, dass das mittlerweile getrennt ist), aber im großen und ganzen hat der Versuch gezeigt, dass es geht und wie es gehen kann.
Nicht gelungen ist uns der Paradigmenwechsel in der Netzstruktur weg von zentralen Gateways hin zu mehr kleinen exits, die direkt auf dem Freifunk-Node laufen können, mit oder ohne VPN. Obwohl der Ansatz viel resilienter ist undwirklich tolle Fähigkeiten schafft, haben wir keine Community in dieser Netzstruktur aufbauen können. Das hat Gründe:
Der Wechsel ist für Communities mit zentralen Gateways fundamental und disruptiv. Das Konzept berücksichtigt (noch) nicht den Beitrag der vielen Menschen zu Freifunk, die aktuell in der Administration von Servern oder Gateways aktiv sind - Wie nehmen wir diese mit in einer Welt in der das für den Netzbetrieb nicht mehr in dieser Form nötig ist? Ein lokales Ausleiten wird von vielen aus guten Gründen nicht gewollt. Die Einrichtung eines VPNs ist aus Node-Betreiber-Sicht ein zusätzlicher Schritt. Das ist nicht gut. Wir könnten nun vorsehen, dass wir diesen und den vorherigen Punkt lösen indem die zentrale Freifunk-Infrastruktur ein bequemer VPN-Endpunkt für Nodes im Netz ist. Den Teil sehe ich nicht in der DNA der Freifunk-Community. Wenn ich "Freifunk ist kein VPN-Ersatz" im Forum und über die Mailinglisten suche, finde ich über die Jahre viele matches. Gleichwohl: Vielleicht geht das in einer Community in der man das von Anfang an so denkt und vorsieht, denn letztlich bieten auch derzeitige zentrale Gateways VPN-Technologie für die Nodes an um das Netz zusammenzuhalten.
Die Gruppe, die das Thema vorangetrieben hat, war nicht klein, aber letztlich hat die Veränderung des Fokus von einigen (z.B. Ich bin Papa geworden - solche Ereignisse verändern die verfügbare Zeit. Umzüge spielen auch eine Rolle.). Mehrere Personen aus dieser Gruppe hatten in kurzer Folge solche Veränderungen und in Summe hat das dazu geführt, dass nicht mehr der nötige Fokus möglich war. Ich bin dankbar für jeden Einzelnen, der mitgewirkt hat. Insbesondere Matthias, Nils, Linus, Dave, Jan, Jürgen, Genofire - das habe ich euch so bislang nicht (oder zu wenig) gesagt, und ich hole das jetzt nach: Danke für eure Geduld eure Energie und euer Wissen, dass ihr kontinuierlich eingebracht habt. Ich habe sehr viel von jedem von euch gelernt und es hat Spaß gemacht.
Man merkt es schon, ich persönlich halte den zweiten Bereich für den schwierigeren. Vermutlich lässt der sich erst dann lösen, wenn eine (neue?) lokale Community das "einfach mal machen" will und dabei eine Lösung für die Ausleit-Frage finden muss.
viele Grüße Christof
~Dezentral Am 04.06.26 um 10:24 schrieb Christof Schulze via WLANtalk:babel macht das mit dem skalieren schon nicht schlecht. Der Bereich, der noch einmal angesehen werden sollte, ist, ob wir durch einen schlaueren Weg der Adressvergabe die routen geschickter zusammenfassen können. Wenn uns das gelingt, haben wir roaming, beliebig viele lokale Wolken und müssen uns auf Anwendungsebene keine neuen Protokolle ausdenken. Das ist dann spätestens der Punkt, an dem direkte VPN Verbindungen spannend sind. Freifunk sollte keine zentrale Infrastruktur brauchen und für Störerhaftungsfragen lässt sich auch ein VPN von lokal öffnen. Ganz im Vorbeigehen lösen wir so auch die Frage, wer die server wartet: niemand. Die brauchen wir dann nicht mehr.
Die Bausteine sind da und wurden sogar im Zusammenspiel erprobt. Es ist nur leider noch nicht gelungen eine Community zu bilden, die das weiterträgt. Der Stand ist, dass die patches aktuell richtigerweise bei gluon wieder draussen sind.
viele Grüße
Christof
_______________________________________________ WLANtalk mailing list [email protected] Abonnement abbestellen? -> https://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net
Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten_______________________________________________ WLANtalk mailing list [email protected] Abonnement abbestellen? -> https://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
-- () ascii ribbon campaign /\ http://www.asciiribbon.org
signature.asc
Description: PGP signature
_______________________________________________ WLANtalk mailing list [email protected] Abonnement abbestellen? -> https://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
