Frei Funk ist frei und von daher finde ich es nicht weiter schlimm, wenns „mal“ nicht da ist.
Ansonsten scheinen wir bei den zeitlichen Kapazitäten der amtierenden Ehrenamts (Linuxler, Geeks Nerds [passendes einsetzen bitte] ja eh schon an der Grenze zu sein … oder?
Ich glaube da gibts wichtigere Dinge.
Gruß chris
Ich fände eine Art 404 Seite schön wenn jemand versucht das Internet zu erreichen, aber nichts geht.
Sie versuchen gerade das Internet zu erreichen, dies geht leider nicht da dieser Freifunk Knoten gerade nicht mit dem Internet verbunden ist. Dies kann mehrere Gründe haben z.b. … Unsere Mesh-Funktionionen funktionieren allerdings auch weiterhin usw usf. Du kannst uns helfen indem…
Das geht (wie mit der Splash Page) leider spätestens bei HTTPS schief.
Wie weit tun sie das eigentlich? Wenn ich kein Internet und damit kein Mesh-VPN habe, habe ich doch so, wie das FFRL-Netz momentan gebaut ist, auch kein DHCP und keinen radvd, also so ziemlich gar nix, oder?
Ja, falls der Benutzx tatsächlich direkt eine https-Verbindung versucht und nicht erstmal eine http-Verbindung, die dann redirecten sollte. Kommt doch auch recht häufig vor.
Außerdem rufe ich zumindest, wenn das Netz irgendwie nicht zu gehen scheint, irgendwas wie Heise oder so auf, um zu gucken, ob das geht.
Also: Ich denke, so eine Splash-Page würde helfen, auch wenn sie nicht alles abdeckt.
Jo. Aber bei IPv6 ist es nicht ganz so schlimm. IPv4 geht in so einem Szenario ja nur extrem begrenzt. Aber IPv4 ist legacy. Insbesondere wenn wir in einem „Lokale Dienste“ / „Internet ist nur ein Dienst im Freifunk“ Kontext diskutieren.
Das geht, wenn HSTS verwendet wird, auch dann nicht. Die Idee ist ganz charmant, es lässt sich nur nicht sauber umsetzen.
Die meisten User haben ein Gerät in der Tasche, welches sich schlicht mit dem Freifunk verbindet und die Apps versuchen ihre Statusupdates durchzuführen, Nachrichten zu holen.
Signalisierung per 802.11u gibt’s funktionsfähig implementiert nur auf Apfel-Oberklassegeräten, ist also zumindest derzeit kein Ausweg (zumindest keiner den ich „barrierefrei“ nennen würde).
Von daher: Keine Freifunk-AP-SSID ist die technisch sinnvollste (weil auch von legacy-Platformen und von jeder App verstandenen) Lösung.
(Alles andere ist „man könnte ja mal, vielleicht klappt das ja sogar…“)
Ich möchte mich @ohrensessel anschließen und anmerken, dass das Memorandum of Understanding da recht deutlich Stellung zu bezieht:
Es ist uns dabei wichtig, dass Freifunk nicht in erster Linie als “Provider für kostenlosen Internetzugang” wahrgenommen wird
(Quelle: https://github.com/freifunk/MoU/blob/master/FreifunkMemorandumofUnderstanding.md)
Wenn die ESSID dann vom Internet-Zustand abhängig ist, dann ist der Fokus schon recht deutlich.
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.
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.“
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?
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
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.
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.
