Ohne jetzt die „Grenzen-des-Wachstums“-Debatte eröffnen zu wollen, so ist die Abplattung der Entwicklung ab Ende 2016 deutlich zu erkennen.
Daher die Frage: Was könnte man tun? Woran liegt es?
Ist Freifunk vielleicht -wenn es funktioniert- einfach zu geräuschlos und macht eben -dank offenem Zugang- zu wenig Reklame für sich selbst bei den Nutzenden?
Nochmal als Nachtrag, damit klar wird, in welche Richtung das Posting gemeint ist (es gab hier „Rückfragen“ auf anderen Kanälen.)
Wenn der Zuwachs stagniert, dann gibt es Gründe
Ein gut performendes Netz zieht weitere Knoten (und umgekehrt)
Eine wie auch immer geartete Sättigung (z.B. „in jedem zweiten Haushalt steht mindestens ein FF-Knoten“ ist noch nicht erreicht)
Wie motiviert man langfristig Leute für den Betrieb des heute notwendigen Backends?
Wo bekommt man Leute her, die für das Backend spenden wollen?
Wenn ein Netz läuft, dann bekommen die Admins keine Anerkennung und die Spender haben den Eindruck, dass das Geld nur dem Komfort der Admins („Server mit Breitreifen und Spoiler“) diente.
Wenn das Netz nicht läuft, dann bekommen die Admins ständig Anschuldigungen, die fakstisch falsche Unterstellungen sind. Also eine Falschmeldung nach der anderen vom Stil „Knoten ist offline“ oder „Freifunk geht überhaupt gar nicht“. Der Kern ist dann jedoch „Netz läuft nicht gut, User beleidigt Admins mit Fehldiagnosen“
Und dann ist man in der Falle,
denn das als als verletzend empfundene Gemecker vertreibt die letzten engagierten Admins.
Neue Admins finden sich nicht, da das Setup dank vieler Kniffe und Notmaßnahmen inzwischen unglaublich komplex geworden ist, dass Neulinge sich da kaum binnen weniger Wochen einarbeiten können.
Spender fühlen sich genötigt, Geld zu geben für ein Netz, was schlecht funktioniert.
Welche Konzepte haben wir zukünftig, um Traffic a) direkt auf Supernodes auzuleiten und b) Traffic direkt auf WAN/VPN-Nodes auszuleiten, um Backend-Kosten zu reduzieren und auch die Abhängigkeit von „Performance“ und „dicke Supernodes“ etwas zu lösen.
Ich sehe ehrlich gesagt nicht die Verbindung dieser Fragen mit der Überschrift (ich hatte eigentlich eine interessante Anekdote oder eine Analyse zu den Gründen der Stagnation erwartet; vielleicht kommen wir ja zu letzterer im Verlauf der Diskussion). Aus meiner Sicht stehen weder a) noch b) in direktem Bezug zum – evtl. – nachlassenden Wachstum. a) als auch b) haben aber massive Auswirkungen auf einerseits die Funktion und infolgedessen andererseits das Design des Netzes, und insofern gehörte die Erörterung zu diesen Fragen eher in einem Technikbereich.
Ich würde »Grenze des Wachstums« nicht ausklammern wollen; wenn beliebte Straßenzüge – sei es durch Anwohner, sei es durch Interessengemeinschaften, sei es durch die/mit der öffentlichen Verwaltung, … – erschlossen sind, stellt sich doch natürlich eine Sättigung ein.
Interessant wäre auch eine Statistik, wieviele Communities von einem aktiven Handeln eher zu einem passiven übergegangen sind — oder durch Aktivistenschwund übergegangen wurden.
Auch nicht zu vergessen: Der Treiber »Flüchtlingskrise« ist weg.
Und: Inklusivvolumen im Mobilfunk steigen, Kosten sinken. Und mit dem Wandel von der WLAN-Wüste zur LTE-Oase sinkt das Verlangen nach WLAN on the road.
Sähe ich jetzt nicht; wieso sollte mein Nachbar, kinderlos und mit eigenem VDSL50, einen Freifunkrouter aufstellen, falls über meinen ebenfalls 50/10 möglich wäre? (Ein Sparfuchs würde eher seinen eigenen Zugang kündigen …)
Meiner Erfahrung nach richtig ist: Interessenten testen das Netz vorher aus, und da kann dann eine temporäre – aus welchen Gründen auch immer – »Minderperformance« schon ausreichen, nicht mehr berücksichtigt zu werden. (›Es gibt keine zweite Chance für einen ersten Eindruck.‹ vs. ehrenamtlich betriebenes Netz.)
Kann ich auch nicht unterschreiben. Gegenthese: »Überall da, wo sie es sich wünschen, haben ›die Leute‹ heute Netz.«
Da zu widersprechen wird schwierig Zur Bewertung hätte ich aber gerne weitere Zahlen, nämlich neben der nackten Knotenanzahl auch die Anzahl der partizipierenden Communities (grob: Anzahl API-Files) und im Grunde auch den Graph der Knoten je Community über die Zeit.
Evtl. wachsen ja kleine und stagnieren/schrumpfen große Communities? Dunno.
Vielleicht fehlen nach Hooding, Domainsplitting und anderen – notwendigen – Maßnahmen zum Funktionserhalt wachsender Netze auch Daten? Würde ich nicht ausschließen; freifunk-karte.de, so sehr ich den Dienst schätze, habe ich jedenfalls auf keinem »things to check after changes«-Zettel. Lies: lokale breaking changes diesbezüglich würden eher nicht zeitnah auffallen … Und unseren Nutzern auch nicht, solange das Netz an sich tut.
Unhöfliche Gegenfrage: Muß man denn etwas tun? Verliert Freifunk seine Existenzberechtigung, wenn nicht jedes neue Monatsende einen neuen Knotenmaximalwert bringt? Ist Freifunk gar ein Schneeballsystem, ein Kartenhaus, das in sich zusammenfällt, ›wachsen‹ keinen neuen, unverbrauchten Knoten mehr nach?
Das »warum« interessiert mich – am Rande – auch. Handlungsbedarf, nur weil ein Graph ein lokales Maximum erreicht hat, sehe ich eher nicht.
Vielleicht setzt Freifunk bei seinen Teilnehmern ein gewisses technisches und politisches Interesse voraus. Vielen ist es egal, wenn der Provider Ports drosselt, kein IPv6 anbietet o.ä., weil sie ihren Anschluss eh nur für WhatsApp und bild.de nutzen. Folglich ist ihnen Freifunk egal.
Nach meiner Einschätzung ist das Interesse der technisch versierten enorm wichtig, dann bleibt es auch bei einem stetigen Wachstum wie am Beispiel Stuttgart, für das ich leider nur ein Wochen Statistik finde, sowie Aachen:
Alle drei sind Communitys die ihr Netz segmentiert haben und somit problemlos auf über 1.000 Knoten anwachsen konnten, mittlerweile machen diese drei Regionen über 10% der Knoten auf dee Freifunk Karte.
Das spricht sehr für dein Annahme, dass Netze nur wachsen wenn die Technik im Hintergrund skaliert.
Meine Erfahrung zeigt außerdem, dass sich grundsätzlich interessierte noch an die massiven Probleme zu Rheinufer Zeiten erinnern können und man ihnen erklären muss wie dies mittlerweile vermieden wird.
Zeitweise schlechte Performance merken sich die Leute also durchaus.
ack. würde ich bei uns hier z.B. langsam so sehen.
war bei uns nie einer.
Das kommt auf die Ursache der Verlangsamung des Wachstums an
auch möglich. da scheitert es aber ja im Gluon-Fall leider immer noch an einer Firmware-Upstream-Lösung, auch wenn derzeit aktiv an zwei Lösungen gearbeitet wird (Segmentierung und/oder Babel)
Die Segmentierung ist eine sehr effektive Lösung die aber leider auch schnell an ihre Grenzen stößt. Die Aachener Innenstadt könnte man sehr gut schon wieder segmentieren, leider ist das aber wegen Mesh Links kaum noch möglich.
Sprich eine Lösung statt des Workarounds wäre enorm wünschenswert, das wäre dann Babel statt der Segmentierung.
In der Tat freue ich mich über Hilfe
Nachdem nun die offensichtlichen und fiesen Bugs aus den Komponenten der Firmware beseitigt sind, geht es nun darum, die nicht offensichtlichen aber dennoch fiesen Bugs zu finden.
Dafür bauen wir aktuell die Infrastruktur auf. Magst Du uns beim Testen helfen? Unter add support for babel routing protocol by christf · Pull Request #934 · freifunk-gluon/gluon · GitHub findest Du den PR für gluon und unter https://dl.ffm.freifunk.net/firmware/babel-dev/sysupgrade/ findest Du den jüngsten Entwicklungssnapshot. Es sollte, abgesehen von netzinternem IPv4, alles funktionieren.
IPv4 nach draußen ist via NAT64 realisiert.
Das ist schon bei DS-Lite-Anschlüssen Realität; solange das Endgerät v4-Gegenstellen erreichen kann, ist imho das »Ziel« erreicht. IPv4 ist seit Jahren ein totes Pferd; je eher wir absteigen können, desto besser.
@Klaus_Dieter, gibt’s auch Hinweise, wie man die Gegenstellen (Gatways aka „Supernodes“) aufsetzt?
a) Bei DS-Lite gibt es IPv4 als „Carrier Grade NAT“ (CGN) seitens des Providers, in der Regel als Nat-Kaskade aus dem Homegateway.
b) bei dem derzeitigen Gluon-Babel-Ansatz gibt es Nat64. d.h. für die Endgeräte gibt es nur IPv6, aber mittels NAT64 im Netz können IPv4-only-Anwendungen und/oder IPv4-only-Services erreicht werden.
a) hilft so ziemlich jedem, der nicht gerade eine „weltweite“-NAS-Freigabe auf IPv4 machen möchte (da gibt es dann andere Notnägel, quasi UPnP auf Steroids für CGN).
b) hilft zwar dem Browser der zu Github möchte oder dem uralten FTP-Client. Aber der ESP8266 und die ältere/billigere Cloud-IP-Webcam sind dann offline.
Aber Androids, halbwegs aktuelle Linux-Distributionen oder auch ein Windows10 haben damit keine Probleme, selbst einem WindowsXP lässt sich das noch beibiegen (wenn man das denn ernsthaft wollen sollte…)
bei Windows2000 weiss ich aber nicht, Windows98 wird jedoch nicht gehen…)
Sprich: Ernsthaft macht es nur Probleme bei Geräten, die man eigentlich nicht im Freifunk haben möchte, weil sie per se unsicher sind aber trotzdem sensible Daten in die Hände bekommen (alte Multifunktions-Scanfaxdrucker) oder weil sie schlicht in die „Internet-of-shitty-things“-Klasse fallen, zu denen man in allerlei Teilaspekten berechtigt jede beliebig radikale Ansicht vertreten kann (meiner Meinung nach.)
Darauf wollte ich hinaus; wenn’s per DNS eine v4-Adresse gibt, regelt das »das Netz« im Hintergrund und liefert die Daten per v6. Fünf Jahre nach dem World IPv6 Launch und dem Leerlaufen des globalen Vorrats an IPv4-Adressen sollte auch Freifunk der stinkenden Leiche IPv4 endlich die Zähne zeigen, IMO.
auch wenn ich eigentlich eurer Meinung bin: DAS stimmt so einfach nicht.
Es sind nicht nur uralte Geräte betroffen, sondern auch Apps/Dienste die statt mit DNS mit hart kodierten IPv4-Adressen arbeiten. Im iOS-Store dürften das keine mehr sein, da ist das seit einer Weile nicht mehr erlaubt.
Aber bei Windows-Programmen und Android-Apps sind da sicher noch einige Kandidaten unterwegs.
Mir wurde z.B. gesagt, dass Steam überhaupt nicht funktioniert mit NAT64/DNS64
Bislang noch nicht, wir bräuchten da mal einen salt-state-nach-Dokumentation-Konverter. In der Zwischenzeit lässt sich die Konfiguration hier einsehen. In kurz: wir arbeiten weiterhin mit fastd, lassen darüber statt batman das babel-Protokoll und den Nutztraffic laufen. Daneben gibt es noch ein paar neue Komponenten (l3roamd, mmfd) die in einem debian-repository gepflegt werden.
Ich schlage vor, dass wir Anwendungen auf einer wiki-Seite sammeln, die mit IPV6-Only + NAT64 nicht zurecht kommen.
Zur Bewertung hätte ich aber gerne weitere Zahlen, nämlich neben der nackten Knotenanzahl auch die Anzahl der partizipierenden Communities (grob: Anzahl API-Files) und im Grunde auch den Graph der Knoten je Community über die Zeit.
