Warum das denn nicht? Ein einzelner Knoten kann innerhalb seiner Reichweite immer noch Clients miteinander verbinden. Vorhin mal das Experiment gemacht. Meinem Uplink abgeschaltet und trotzdem konnte ich noch zwischen iPhone und Laptop Daten austauschen. Internet ging dann über LTE. Als ich den Uplink wieder zugeschaltet habe, hat das iPhone wieder ganz normal über Freifunk Internet gehabt. Mein Android Smartphone verhält sich da leider ganz anders. Solange es mit WLAN verbunden ist, schaltet es nicht zusätzlich auf UMTS um, wenn über WLAN kein Internet erreichbar ist.
Sowas können aber Smartphones nicht richtig. Die routen alles über eine Verbindung.
Stimmt nicht ganz… Sowas können einige Smartphones nicht richtig…
Bei mir funktioniert das hier aus super! In der Praxis ist ein FF Node ohne Internet bzw. als Insel nicht sehr hilfreich, da die Clients nichtmal eine IP Adresse bekommen. Im Normalfall haben sie dann nähmlich auch keine Verbindung zum Supernode.
Du hast aber schon bemerkt, dass wir hier eine Lösung mit „zwei AP-SSIDs“ (eine steht, eine bleibt) anstreben?
Darüber hinaus: das MoH ist durch nichts legitimiert und durch keinen nachvollziehbaren Prozess übergestülpt worden. Darüber hinaus werden immer nur einzelne Passagen herangezogen, andere -der eigenen Position nicht passende- jedoch weidlich ignoriert.
Das Ding hilft nicht in Diskussionen, es schadet.
2 „Gefällt mir“
Sie wird dann davon abhängig gemacht ob eine Verbindung zu einem Gateway (im Batman Sinne) vorhanden ist.
Bei Gluon ist das eine Bedingung um überhaupt dhcp anbieten zu können.
Solange die Community vor Ort einhellig einer Meinung ist, kann mir egal sein was irgendwelche Leute in dieses Manifest hinein interpretierten.
Dies stellt auch das von dir zitierte Dokument fest:
„Diese dezentrale Organisationsstruktur fördert bewusst lokale Aktivitäten, statt sie von einer übergeordneten Entität steuern lassen zu wollen.“
2 „Gefällt mir“
Stimmt auch nicht ganz… Sondern nur, wenn man Gluon oder ein ähnlich zentral organisierte „Freifunk“-Systeme einsetzt. Hier hat jeder Node einen eigenen DHCP. Theoretisch könnte das Internet 4 Wochen ausfallen, ohne das es separate Knoten kratzt oder das Netz neu organisiert würde, lokale Kommunikation in den Wolken wäre noch länger möglich, sofern sich die Dienste in den Wolken befinden.
Also schiebe ich den ganzen Kremel zu Gluon, oder?
1 „Gefällt mir“
Ich gebe zu, ich hab hier jetzt nicht alle Beiträge gelesen. Aber um kurz zusammen zu fassen, wie wir das Problem lösen. Bei uns wird im laufenden Betrieb die SSID gewechselt. Hierbei werden alle Clients, die die neue SSID nicht kennen vom Hotspot gelöst, alle die die neue SSID kennen bleiben verbunden.
Wenn man nun xyz.freifunk.net und xyz.freifunk.net-NOINTERNET verwendet, beispielsweise, dann bricht weder ein interner Dienst ab, noch ein Dateitransfer. Denn die Endgeräte die beide SSIDs kennen bleiben einfach verbunden.
Das Script was es dafür seit ner Weile bei uns gibt, hängt derzeit noch den Node-Namen an, bei uns ist das Ziel in dem Fall eher debugging, welches Gerät grade klemmt, weil Ad-Hoc sich aufgehängt hat, als konstante Dienste am Laufen zu halten - denn diese sind bei uns ausnahmslos, soweit ich bisher hörte, mit LAN-Kabel zu einem Node verbunden. 
LG Ruben
5 „Gefällt mir“
Also ich bin bei dieser Diskussion etwas hin- und hergerissen. Klar ist es scheiße, wenn Freifunk irgendwo verfügbar ist, aber kein Internetzugang dran hängt. Mich persönlich würde das nicht stören, aber es gibt sicherlich Einige.
Andersherum erinnere ich mich ungern an die Freifunk-Firmware zurück, die noch ohne Domänenkonzept lief, wo jeder Knoten eigener Exitpoint war. Da lief nämlich auch ein „Skript“ was den Internetzugang testete. Leider lief das nie wirklich gut, also potentielle Fehlerquelle, die wir nicht unbedingt haben müssen.
Ich würde aber gerne versuchen das Pferd mal von hinten aufzuzäumen. Wieso kommt es denn überhaupt vor, dass mal kein Internet an einem Knoten ist? Ist das nicht in so einem Fall nur von kurzer Dauer, etwa wegen einer Störung?
Jedenfalls fände ich wär der eleganteste Weg dafür zu sorgen, dass soetwas möglichst nicht passiert. Je engmaschiger das Netz wird und je mehr Teilnehmer den Zugang zum Internet freigeben, desto geringer die Chance für ein Problem dieser Art.
1 „Gefällt mir“
Ich hab mich jetzt noch nicht näher damit beschäftigt, möchte aber mal eine Frage stellen:
Warum startet das Script den Knoten nicht neu statt die SSID zu ändern?
In einer nennenswerten Zahl von Fällen behebt ein Neustart das Problem und das Internet steht wieder zur Verfügung.
Ich habe hier öfters beobachtet das sich Nodes mal Komplett aufhängen. Dann hilft nur ein Neustart.
Vielleicht wäre das aber als Zusatzfunktion in dem Script nicht Schlecht. Scenario:
Kein Internet mehr > Neustart > Bootet > Internet da > Fertig
Kein Internet mehr > Neustart > Bootet > Internet immernoch weg > SSID umbennenen und alle x minuten wieder PrüfenDas häufigste Problem im Ruhrgebiet ist „keine Tunnel frei“ - da würde das nicht weiterhelfen.
So als eun Versuch finde ich das nicht scnlecht, nur nicht als Solomaßnahme.
Es passiert wenn Router in irgendwelchen WGs oder Firmen stehen und schlicht vergessen werden. Kabel „zum Internet“ irgendwann mal beim Räumen herausgezogen, kein Wifi-Meshpartner in der Nähe (nie gewesen). Keine Kontaktinformationen im Router hinterlegt, das Ding funkt einfach weiter.
Oder Autoupdater nicht aktiv, aber die meshvpn-Server haben sich geändert… und niemand kümmert sich um die Kiste, es gibt keine Ansprechpersonen… Trotz Internet am Wan: Kein Gateway. Selbst Wifimesh geht nimmer, weil sich der Wlan-Kanal geändert hat. (Zukünftig: weil sich sich die Batman-Version geändert hat.)
Will sagen: Nein, es ist unschön, aber schlicht nicht zu ändern.
vgl.
1 „Gefällt mir“
Bei solchen Knoten hilft es dann aber auch nicht, wenn wir eine neue Firmware schreiben mit welchem Workaround / welcher Lösung auch immer. Die Knoten bleiben ja trotzdem dann dort, wo sie stehen. Hilft halt eher nur für künftige Knoten, und diese Problematik halte ich für überschaubar bzw. lösbar.
Ich wäre tatsächlich dafür die Knoten aufzuspüren und unschädlich zu machen. Ich helfe auch gerne.
Eine App wär nicht schlecht, die anzeigt, ob Knoten in der Umgebung sind, die z.B. noch auf dem falschen Kanal senden, oder über die keine DHCP Replys kommen.
Let’s play seek and destroy. 
Na klar hilft das: Dann richten diese Knoten nämlich schlicht keinen Schaden mehr an indem sie NutzerInnen anziehen, die dann dort kein Internet bekommen (was sie eigentlich erwarten würden.)
Und zu sagen „Wir bauen aber doch kein ‚Abschalt-Konzept‘ in neu zu installierende Router ein“ („lass sie uns lieber so bauen, dass sie gar nicht offline fallen können“):
Frommer Wunsch! Und Blauäugig!
Das entspräche dem Verhalten von Konsumgüter-Produzenten, die sich jahrelang geweigert haben, Entsorgungskonzepte (für das "End of Life-Szenario) in Produkte mit hineinzudesignen. Frei nach dem Motto: „Wir können bei einem neuen Gerät doch in die Bedienungsanleitung nicht hineinschreiben, wie man das Ding wegwerfen soll!“.
Doch kann man, sollte man, muss man!
Dass es dann hinterher noch ein 2nd life geben kann nach einem Refurbishment oder einem echten Recycling auf Baugruppen-Ebene oder durchlaufen eines Reparaturcafes: Unbestritten. Aber ein Gerät da ist, dafür muss vorgesorgt sein, für eben den leider üblichen Worst-Case.
Und das brauchen wir für die Freifunk-Touter auch.
Wenn es am Ort einen Pebrille gibt, der Haftnotzizen aus Haustüren klebt und BewohnerInnen anspricht, ob sie wüssten, wo „dieser Freifunk-Router“ steht: Been there, done that. Aber wenn nicht, dann muss es einen Default-Plan geben der bis dahin greift. Oder eben allein wirksam ist, wenn sich niemand vor Ort findet, der abandonned FF-Router jagt.
1 „Gefällt mir“
Ich rede von bereits aktiven Knoten, nicht von Knoten die in Zukunft verwaisen werden. Nur für Knoten die nach der Implementierung dieser Lösung installiert werden, hülf dieser Ansatz.
Blauäugig? Ich? Nein. Ich denke nur, dass wir möglichst wenig unnötige Komplexität in die Firmware bringen sollten. Die Komplexität und auch das Fehlerpotential der Firmware zu erhöhen, muss überdacht werden. Da wollte ich anregen drüber nachzudenken. Hinzu kommt, dass solch eine Lösung auch möglichst zukunftssicher für künftige Gluon-Versionen sein sollte, sonst müssen wir für dieses Feature immer nachimplementieren. Dass Gluon diesen Ansatz von Haus aus mit aufnimmt halte ich nach jetzigem Gefühl nicht für wahrscheinlich.
Ich glaube einer der tiefgehendsten Probleme die wir mit dem Freifunk haben ist, dass wir das als bürgerlich betriebenes Netz betrachten. Nur leider sind die Bürger nur formell Betreiber, und in aller Regel nicht administrativ. Da find ich es viel blauäugiger zu glauben, man könne ein Netz dauerhaft am Funktionieren halten, ohne dass es für die Knoten Admins gibt. Die Freifunk Firmware ist ja mit Gluon schon wirklich ein Stück gereift, aber zu glauben wir hätten hier die eierlegend Wollmilchsau (im Sinne von: „ist so gebaut, dass sie immer funktioniert, und wenn nicht, dann wenigstens nicht stört“), ist nicht realistisch.
1 „Gefällt mir“
Korrekt.
Die Vergangenheit kann niemand ungeschehen machen.
Aber man kann ja lernen für die Zukunft.
(Und die Altlasten musst man dann eben jagen oder als solche schlicht verdrängen plus das Argument bringen, dass „gute Mobil-Betriebsysteme“ damit umzugehen wüssten. Getreu dem Motto „schmeisst die alten Androids weg wo es keine Updates mehr gibt oder kauft gleich Apple“)
Nunja. Das MoU in der Fassung ist, bestenfalls, WiP. Ich halte jene Fassung derzeit nicht für konsensfähig.
Kannst Du jene Skripte veröffentlichen? Auch mit dem Gluon-Feature „Private WLAN“ laufen wir in eine doofe Falle: jenes Netz wird auch ohne Uplink gestartet, somit haben wir bestenfalls private WLAN ohne Verbindungen …
Ipv4 Adressen werden hoffentlich bald auch in offline Wolken verteilt, dank des neuen dynamischen DHCPd pyddhcpd Servers: https://forum.freifunk.net/t/experimenteller-server-fuer-verteiltes-dhcp