vermutlich eine blöde Frage, aber wer ist diese 172.16.1.10?
bekomme dazu leider kein reverse-lookup, geschweige denn das ich den von irgendwo erreichen kann.
Drüber hinaus wäre es im Rahmen der Fehlersicherheit vermutlich sinnvoll, mehrere Hosts abzuklappern, damit nicht der Ausfall eines einzigen Hosts (oder loadbalancers oder dns-records) sämtliche APs runterzieht.
Die IP unseres internen Radius Servers, tut hier also nichts zu Sache, habe ich nur als Platzhalter drin gelassen. Mehrere Host zu befragen haben wir uns gespart, hinter der einen IP stecken drei Server die sich den Service per high availability schnappen falls die anderen ausfallen.
Ich meine beim Freifunk auch gesehen zu haben, dass es virtuelle IP Adressen gibt die immer auf dem überlebenden Host aktiviert werden, das wäre optimal. Ansonsten ist es ja kein Problem das ganze für mehrere Adressen anzupassen.
Ihr sägt Euch Freifunk einfach so ab, wenn es nicht in Internet Routet? Herrlich. Wieviel muss ich Zahlen, damit ich mich mit meinem Schmartfon über irgend ein Freifunk-AP zu meinem VPN zu Hause über Freifunk verbinden kann? Dies funktioniert im Gegensatz zu einem GW ja noch.
Geteiltes Leid ist kein Leid …
Euer Vorschlag ist im Übrigen eine geniale Fehlerquelle, wenn man mal eben zu Hause Staub hinter dem Router wischt oder die Fenster Putzt … so wie ich das Sehe baut ihr ein Dezentrales, sich selbst organisiertes Netzwerk auf, das irgendjemand einfach so abschalten kann, in dem er schäbige Pings/t nicht durchlässt. Toi, toi, toi 
Natürlich habe ich auch all die schönen Darknet-Träume.
Aber sorry, bitte schaue doch mal auf die Realität: 99% der Nutztdaten der Clients bleiben NICHT im Freifunk, sondern gehen zu Diensten im Internet.
Und wegen der letzten 1% verärgere ich ungern die erdrückende Mehrheit der BenutzerInnen.
Die wollen -genau wie ich- einen DHCP, der ihnen einen Adresse herausrückt und dann ins Internet.
(Und das schreibt hier jemand, der nach wie vor einen lokalen inn und einen UUCP-Server betreibt.)
Und vergess nicht dieses IPv4 das will hier auch noch jeder haben … Achne dhcp haste ja schon erwähnt 
Immer mit der Ruhe Leute, ich habe hier die Methode zur Diskussion gestellt die in unserem lokalen, nicht Freifunk WLAN, schlicht funktioniert. Beim Uplink Verlust zu einem Haus schalten sich alle APs in diesem Haus ab, die Bewohner laden also zuverlässig auf APs in anderen Häuser.
Für FF ist der Ansatz wie geschrieben anzupassen. Wie steht es denn um die Informationen aus der Netzübersicht. Es ist doch sicherlich einfach die Zahl der VPN Uplinks die Lokal auf dem AP und im erreichbaren Mesh zu Verfügung stehen zu ermitteln.
Erzählt mir von einem realen Fall in dem mit FF noch etwas anzufangen ist wenn diese Summe auf 0 fällt. Falls sich das in der Zukunft ändert, was ich mir sehr wünsche, ist das ganze anzupassen. Dafür muss das Netz aber zunächst wachsen.
Ich baue Freifunk auf, damit es mir niemand abschalten kann. Ich wäre sehr traurig darüber, wenn mir die APs wegbrechen würden, nur weil irgendwo ein Ping nach nirgendwo nicht in der notwendigen Anzahl pro Zeit beantwortet wurde. Mit einer Informationsseite, was im Fehlerfall zu tun ist wäre, die Zeit mMn besser verbracht. Außerdem käme unser Verein so seinem Bildungsauftrag nach …
ich kann mich immer noch mit A nach B über C verbinden. Das ist Freifunk. Zum Glück kann mein Laptop mit Batman meshen. Für meinen Smartphone muss ich mir wohl den kleinen, Batteriebetriebenen TP-Link mit Batman kaufen. Da kann ich eine IPv4 manuell einstellen. Danke für die Vorwarnung Eurer Pläne.
Ich traue Dir durchaus zu, auf den Freifunk_NoInternet (oder wie immer er dann heissen wird) auszuweichen, wenn die SSID sich entsprechend geändert hat.
Meine Daten, die deine Netzwerkinfrastruktur passieren, werden also störend beeinträchtigt (die TCP-Session bricht ab), weil es irgendwo keinen Internet gibt? Was ist bei wiederkehrenden Problemen, muss ich mit 12 SSID Änderungen pro Stunde rechnen?
Die Erfahrungen, die ich mit dem Ausfall des Internets gemacht habe waren Folgende: „schade, dass es jetzt keinen Internet gibt, hoffentlich habt ihr das Problem bald behoben. Danke für den Tollen Freifunk“ und keine Morddrohungen meiner Familie.
Ja.
(Sorry, aber können wir das „wir sind autak vom Internet“ nicht vertagen bis wir wirklich ein benutzbares Mesh plus einen realen Use-Case haben? Und ja, ich baue daran mit, mit vielen Routern, mit Richtfunkstrecken. Aber noch sind wir nicht einmal ANSATZWEISE dort.)
Ich glaube, das Problem, das man hier durch Deaktivierung des WLAN entschärfen möchte, ist, wenn man keine Verbindung zum Supernode hat. Ohne die geht kein Internet, ohne die geht auch das VPN zu @phip nach Hause nicht.
Wir müssen einfach sinnvolle Kriterien finden, wann das WLAN deaktiviert werden soll.
@phip Ich vermisse noch immer die reale Anwendung die bereits existiert die wir beeinträchtigen.
Existierender Datentransfer wird abgebrochen, weil irgendwo ein Sack Reis umgefallen ist (entschuldigt die Formulierung)
Ich verstehe, wenn der Knoten ausgeschaltet wird. Ich verstehe, wenn es Probleme mit der Verbindung der Knoten untereinander gibt, ich verstehe, wenn der Knotenbetreiber den Knoten einfach nie wieder einschaltet, aber ich verstehe nicht, dass man einfach so mutwillig die per Konvention definierte SSID ändert.
Wie sollte die ausweich-ssid denn heissen?
Welcher Datenverkehr? Wir wollen dann SSID switchen wenn aus unserer Sicht keiner mehr möglich ist, weil es keine Gegenstellen mehr gibt. Ich wiederhole mich ungern, bitte nenne eine reale Anwendung.
Kriterium 1 sollte man lokal auf den Knoten implementieren. Das ist meiner Meinung nach auch der wirklich kritische Fall. Das sind Knoten die über Monate ohne zu funktionieren FF ausstrahlen, die ruinieren den Ruf von FF. Davon haben wir in Aachen immer noch welche.
2 von jeder FF Kiste im Felde prüfen zu lassen macht recht viel rauschen.
3 ist nice to have, das sind aber Knoten die aus dem FF Kernnetz zu erreichen sind, für solche Fälle habe ich bei mir im Netz Skripte zur Hand, die manuell gestartet werden und automatisch per ssh alle APs umkonfigurieren, falls es mal wirklich lange dauert.
Existieren denn ähnliche Möglichkeiten für die Wartung der FF Knoten?
Sind wir schon so weit eine SSID auszusuchen?
„Freifunk-noInternet“ oder „Freifunk-lokal“ gefallen mir.
„Freifunk-noInternet“ ist in jedem Fall auch für den Laien eindeutig. Immerhin geht es ja darum, potentielle „NurSurfenWoller“ gar nicht erst mit falschen Hoffnungen zu locken.
Ich stelle mir vor:
SSID „Freifunk“ nur wenn
a) mindestens ein Supernode („batctl gwl“) zu finden und gleichzeitig
b) DHCP-Server funktionsfähig (wie testen ohne dhcp-requests/offers)
c) DNS verfügbar
b) und c) mag redundant erscheinen. Leider aber auch schon anders erlebt.
Mein Ansatz: Fertiges Gluon-Modul bauen, was dann jedeR nach eigenem Gusto im ConfigWizzard an/abschalten kann, Voreinstellung durch site.conf der Community.
du meinst à la Captive Portal, damit die Leute wissen, warum sie grad nicht surfen können?
dir wäre es also lieber, wenn das WLAN ganz verschwindet, anstatt sich die SSID ändert?
Also ich muss heir @phip recht geben. Es kann nicht sein dass das Interface abgeschaltet wird. Verstecken OK aber nicht abschalten.
Selbst wenn nur 1% der Leute das Wlan auch für andere Dinge als nur Internet nutzen so müssen wir auf diese Rücksicht nehmen. Ergo → Wird nicht eingebaut
Außerdem verstößt es in meinen Augen auch gegen das Pico Peering und zwar:
Punkt 1. Freier Transit
„Der Eigentümer bestätigt, die Daten, die seine freie Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch zu verändern.“
Störend wäre hier das abschalten des Wifi Interfaces. Wenn wir uns schon an die PPA halten dann bitte auch vollständig und nicht nach Lust und Laune
Im übrigen funktioniert das Script oben so nicht da es das gesammte Wifi abschaltet und nicht nur den AP. Dafür sind Config Änderungen notwendig die per Gluon Modul geregelt werden sollten und nicht als Bastel-Cronjob-Script.
Nein. Wenn das WLAN abgeschaltet ist, passieren keine Daten seine Netzwerkinfrastruktur.
Ja, das müßte angepasst werden. Wenn ich das richtig verstanden habe, stammt das Skript auch nicht aus einer FF-Umgebung.
Dann dürfen Wifis generell nicht offline gehen wenn noch Clients drin sind, allerdings für die ganze lokale Wolke. Roaming muss weiterhin funktionieren für Clients die das Netz intern nutzen.
Einfach abschalten ist ein störender Eingriff in den Datentransfer, genau so als ob man es per Ebtables filtert.
Richtig, müsste angepasst werden. Wer macht das? Shell - Scripts zum selber installieren ist nicht der richtige weg und damit verbundene Probleme werden von uns garantiert nicht supported.
Es muss ein Gluon Module sein, dazu zählt halt eine gewisse Einarbeitungszeit in Gluon damit sich keine Race-Conditions durch sich störende Funktionalitäten bilden. Dazu kommt eine angemessene Testphase.
Vorher bitte ich auch davon abzusehen dieses Feature mit Selbstbau-Anleitung hier bereitzustellen da es evtl von Leuten installiert wird die nicht so viel Ahnung von Linux und Embedded Devices haben.
Wir wollen ein Qualitätslevel an Firmware, schon alleine organisatorisch können wir keinen Support für eigene Basteleien geben. (Sprich falls Störungen auftreten und das Netz nicht funktioniert an der eigene Node)