Hallöle,
wer arbeitet derzeit an dem Script: http://pastebin.com/cPRgg1Hj
Sobald das komplett lauffähig ist, wäre es möglich dieses über die Webgui zuschaltbar zu machen und als gluon Paket zu erstellen, so dass wir dieses per default mit in unsere Images einbacken können?
Gibt es dazu einen Thread?
Grüße
Chris
ich glaube dass ist schon fertig - Andreas Dorfer fragen.
Bis jetzt hat daran niemand gearbeitet, also an dem Gluon Paket. Das Script war noch Race-condition behaftet.
p.s.
Übrigens kann die „Ampel“ die ihr im Ruhrgebiet habt dafür sorgen das der AP das Wifi an und aus flippt ;).
Nein, "fertig " ist es noch lange nicht, dafür braucht es mehr als „schaltet AP-SSID um immer wenn man die Neighbours abschaltet/das WAN trennt“.
Ich bin mir z.B. nicht sicher, ob man dem Flash die Schreibzyklen zumuten sollte und ob es nicht einen Hardware-schonenderen Weg gibt, den AP umzuschalten.
Ja, jedes /sbin/wifi sorgt dafür, dass das ganze Wifi potentiell wackelt, auch das adhoc-mesh.
(Dass einzelne Nodes die AP-SSID im schlimmsten Fall minutenweise umbennen, wenn der Router keinen Weg ins Internet findet: Ja, das ist dann so. Und auch genau so beabsichtigt.)
Exakt, da haben @adorfer und ich dran gearbeitet. Ich nutze das auch schon so auf meinem akku betriebenen Access Point den ich gerne mal mit mir herum trage.
Mit den Kriterien sind wir allerdings noch nicht zufrieden.
Wir hatten uns daher überlegt als primäres Kriterium „batctl gwl“ oder ähnliches auszuwerten um so ganz ohne Netzwerk traffic zu verursachen ermitteln zu können ob das mesh einen gateway kennt.
Problem ist dass diese Information nach ersten Tests erst ziemlich träge toggeln würde.
Naja, besser träge als hektisch, oder?
Was ist denn so das resultat? 5Minuten? 10 Minuten?
(Für einen mobilen Node vermutlich eher nicht sinnvoll, aber für einen stationären sollte das reichen.)
Ja, in etwa in dem Bereich. Wenn man das dann dafür minütlich abfragen würde stellt man sicher dass das Internet nicht übereilt abgeschaltet wird und das WLAN trotzdem schnell wieder da ist sobald der Fehler behoben ist.
Um die Speicherabnutzung der Geräte musst dir übrigens keine sorgen machen machen. Wir commiten die Änderung nicht, daher bleibt das ganze im RAM overlay.
Und ich würde warten, bis die Prüfung zweimal nacheinander (mit Abstand) versagt.
Also Prüfung (batctl gwl / batctl ping auf den gwl) mit je 3 Paketen in Minutenabstand. Fehlerzustand wahlweise „gwl leer“ oder „keine Ping-antwort“).
Wenn also der Batman erst nach 5 Minuten reagiert und dann die Prüfung noch zweimal schief läuft: Dann dauert es ggf. 7 Minuten „bis offline-SSID“ und vermutlich auch so lange bis wieder oben: Völlig ausreichend meiner Meinung nach.
Magst Du ein Gluon-Paket daraus zu backen? (Ich habe keine Ahnung, wie das geht… sorry.)
Ich denke nicht, dass das notwendig ist. Batman adv führt ja bereits alle 5 sekunden entsprechende tests durch. Der last seen Wert der Einträge hat teilweise dreistellige Werte. Es wird also von Batman adv erst nach vielen erfolglosen Versuchen das Netz umzugestalten tatsächlich der Gateway verworfen. Wir können also nach meiner Meinung mit gutem Gewissen auf den zusätzlichen, wenn auch ausgesprochen geringen, Traffic durch eigenen Prüfungen verzichten.
Hier hätte ich aber gerne noch eine Bestätigung von jemanden der sich schon länger mit Batman adv beschäftigt.
Nach genau so einer Lösung suche ich.
Sie würde folgendes Problem lösen:
Router A hat einen Internet-Uplink und sieht nur B
Router B ist ein reiner Mesh-Knoten und sieht A und C.
Router C ist ein reiner Mesh-Knoten (oder eine ganze Wolke an Mesh-Knoten) und sieht nur B.
Wenn B ausfällt, erhalten alle Clients im Mesh dennoch eine WLAN-Verbindung, versuchen dann aber vergeblich eine DHCP-Kommunikation. Die Nutzer sind maximal verwirrt, weil der Rechner eine WLAN-Verbindung anzeigt, aber nicht vollständig aufbaut.
Noch blöder ist es für WLAN-Clients am Standort von B. Diese verbinden sich mal mit dem funktionierenden Knoten A und mal mit dem in der Luft hängenden C. Damit stört C mit seinem Verhalten sogar den ansonsten funktionierenden „WLAN-Raum“ um A.
@MrMM und @adorfer : könnt Ihr hier vielleicht nochmal schildern, was genau an dem Skript noch suboptimal ist, damit andere kreativ unterstützen können?
Hier zu einer Gluon-Erweiterung zu kommen, wäre wirklich toll.
An dem Script ist nicht optimal, dass die Gluon-Entwickler sich damit der Kritik (aus Berlin und anderen Communities) ausgesetzt sehen, einen zentralistischen „Inetnet-Hotspot“ zu fahren.
Wichtig soll es vielmehr sein, die Nichtverfügbarkeit von Internet in einer Freifunkwolke als Chance zu begreifen, sich auf lokale Dienste zu besinnen.
Oder um es klarer zu sagen: Die Mehrheit der Entwickler wünchst so ein Skript explizit nicht. Daher wird es das nicht geben von Leuten die Ahnung haben.
Und die Leute, die es dann machen, haben nicht genügend Ahnung, um sich nicht vorhalten lassen zu müssen, dass es so nicht hinreichend zuverlässig funktionieren wird respektive die Zuverlässigkeit nicht erwiesen ist.
Wir haben letztens mal einen grundlegenden Test mit dem Output von
batctl gwl
gemacht.
Das ist zwar relativ träge, was das erkennen eines verschwundenen Uplinks angeht, aber einige Minuten Reaktionszeit reichen ja aus.
Dafür ist der impact auf das Netz minimal, denn es müssen keinerlei Daten übertragen werden und nur ein Kommando mit sehr wenig CPU Zeit ausgeführt werden.
Bei uns in Aachen herrscht, soweit ich es überblicken kann, der Konsens, dass Knoten ohne Kontakt zu einem Gateway mit dem besten Mesh nichts anfangen kann und daher die ssid ändern sollte.
Fehlt also nur noch die Zeit es in ein gluon Paket zu backen.
Oder das KnowHow…
Auf jeden Fall hat es noch niemand getan.
Doch, es hat schon jemand getan: GitHub - VfN-NRW/offline-ssid: Offline SSID-Script for Freifunk-Router
Sehr schick, ihr habt dieses schöne Stück Code inzwischen in gluon gebacken.
Start auf offline ssid gefällt mir sehr gut.
Ihr macht enorm viele checks auf den Knoten, der Start mit vorhandenen Daten von Batman ist genau was ich mir vorstelle.
Warum macht @RubenKelevra im Anschluss noch mit ping checks weiter? Hattet ihr tatsächlich Fälle in denen euer Gateway den Knoten bekannt war, es aber trotzdem kein Netz gab.
Ja, da sind extrem viele Checks drin, was mir sagt: Da hat jemand wirklich schon länger mit gearbeitet und Gehirnschmalz investiert.
Mag mal jemand versuchen, das gegen ein 2015.1er-Gluon zu compilieren?
Mir ist ist gerade nicht klar, ob es nicht sinnvoll wäre, noch eine Option in einem config-setup-wizzard mit einzufügen.
Und ob man nicht mit wenig Aufwand so auch noch die zweite „ff-wolke“ (die auch im NoGW-Modus oben bleibt) hinbekommt.
Und dafür im „Offline“ die primäre Online-SSID komplett herunter nimmt.
unter der Gefahr, mich zu wiederholen. Nur weil der Internet Uplink des Gateways nicht funktioniert (= das Gateway announced sich in batman nicht als Gateway) heißt das nicht, dass das Freifunk „offline“ ist. Es gibt Dienste im Mesh, es gibt auch ohne Gateways IPv6 zur Kommunikation…
Bitte lese Postings bevor Du Antworten schreibst.
Danke.
(Um nicht zu sagen: Du hast mein Posting mindestens völlig falsch verstanden. Oder schlimmeres.)
meine aussagen gelten auch nach abermaligem lesen deines posts
O.k. Du störst Dich also an der Bezeichnung „offline“ für die Variable, respektive die Kommentarzeilen.
Sollte als nach „NoGatewayInReach“ umbenannt werden? oder was wäre Dein Vorschlag?