Naja, wenn Du auf einem 841er viel mit Portforwarding baust, dann musst Du schauen, wie Du das z.B. über die /etc/rc.local einhängst (wenn es einfach ist) oder wenn Du komplexere Startscripte in /etc/init.d&Co braucht, dann über einen Check in der /etc/rc.local eine „Reinstallation“ der Startscripte triggerst.
Problem ist halt, dass Du auf den Autoupdater der FF-Community sinnvollerweise nicht verzichten solltest, da es durchaus Szenarien gibt, in denen binnen weniger Tage ein Autoupdate ausgerollt werden muss und alle, die es nicht „nehmen“, entweder offline sind oder -schlimmer- das Netz weiter belasten.
So, eben war ich mal wieder etwas langsam in der Denke, jetzt hab ich geschnallt, dass es um den Autoupdater geht.
Mir ist noch unklar, ob die /etc/-Ordner beim autoupdate ueberschrieben werden oder geloescht, werden sie denn geloescht? Ich hatte die Hoffnung, dass dort nur „ueberschrieben“ wird.
Ich habe nicht vor, den autoupdate zu deaktivieren.
Wenn man hier MQTT in die Suche eingibt, dann bekommt man nichtmal eine Handvoll Treffer.
Gibt es einen Grund, wieso dieses Protokoll so stiefmuetterlich behandelt wird? Wird der ganze Datenhaufen, den die FF-Wolke da jeden Tag produziert noch per http „zentralisiert“? Welche Protokolle kommen da fuer die Statistiken zum Einsatz und wieso nicht MQTT?
Es ist die alte Diskussion, dass es prinzipiell n Datensammler im Netz geben können soll. Und das auch ohne „zentralistische Genehmigung“.
d.h. es scheitern alle Protokolle, bei denen sich Knoten bei nur einem/zwei Kollektoren subscriben können. (Oder wie immer auch das jetzt geregelt ist mit push oder pull)
In wie weit das sinnvoll ist oder nicht und ob es vielleicht auch andere Konzepte gibt, die die Anforderung(en) erfüllen können, das sollte man vielleicht in einem separaten Thread betrachten.
Auf der Suche nach Möglichkeiten, wie man gluon-basierte (Freifunk-)Router an die Heimautomatisierung anbinden kann, bin ich hier gelandet, und möchte diesen Thread nochmal anwärmen.
Meine ersten Basteleien bestanden auch darin, auf dem FF-Router mit „mosquitto_pub“ und einem Cronjob 5-minütig JSON-Infos an den MQTT-Broker im Heimnetz zu publizieren… Das hat einigermaßen funktioniert, aber offensichtliche Nachteile.
Jetzt ist mir noch was Anderes eingefallen - vielleicht gibt es Meinungen dazu:
Ziel ist ja, den Bedarf installierter SW auf dem FF-Knoten minimal zu halten.
Auf dem FF-Knoten ist ja respondd schon enthalten.
Gibt es eine Respond-Client Software, die auf dem Raspi laufen könnte, und deren Ausgabe man verskripten könnte, um sie an den MQTT-Broker zu „pumpen“?
Oder ist das eine Sackgasse/Irrweg?
Letztendlich wäre es aber schön, etwas Upgrade-festes zu haben, mit dem man auch aktiv am FF-Knoten etwas steuern kann, zB das private WLAN aus- und einzuschalten, oder abends das Freifunk-WLAN wegen der Kinder ausschalten kann, ohne eine Zeitschaltuhr verwenden zu müssen. (Ich weiss, cron-Jobs gäben auch eine, aber leider etwas starre Möglichkeit ab, letzteres Ziel zu erreichen).
Auch würde ich letztendlich auch gerne Presence-Detection für ausgewählte Smartphones im FF-Netz ermöglichen, um Lichter an- und auszumachen, wenn niemand daheim ist. (Kinder sind bei mir nur im Freifunk-Netz)
Einerseits haben wir dafür einen Patch (»Nachtruhe«, schaltet zwischen 22 und 6 Uhr die AP-SSID aus), andererseits halte ich schon den erzieherischen Ansatz dahinter für Bullenscheiße (wir haben das gebaut für z. B. Fußgängerzonen, wo sich in lauen Sommernächten Nutzer zu Telefonaten häuften). Meine Kinder haben, seit sie ein Smartphone haben, auch einen Datenvertrag; schalte ich also ihnen das WLAN ab, gingen ihre Endgeräte stumpf in die Mobilfunkkonnektivität, auf meine Kosten. Wir haben das bis zum Alter X so gelöst, daß die mobilen Geräte nachts im Wohnzimmer geladen wurden — also effektiv der Nutzung im Kinderzimmer entzogen. Aber eben auch nur nachts, sprich wenn die Kids schlafen sollen; zwischen Aufstehen und Schlafengehen gab und gibt es keine Restriktionen — und gefülhlt ›übermäßiger‹ Konsum dazwischen wird thematisiert und diskutiert.
Das ist definitiv nicht der Sinn eines Freifunk-Netzwerkes.
ich denke das steht und fällt hier mit der Formulierung „aktiv am Knoten“.
Imho ist das eigentlich eine Serverleistung und nicht die des Netzes.
Es steht natürlich jedem frei seitlich an seinem embedded kernel was anzuflanschen in beliebiger kompatibler Abstimmung mit seiner Community, aber eine originaere gluon Aufgabe ist das wohl eher nicht. Es gibt da ohnehin 47000 Ruecksichtnahmen und Abhaengigkeiten, da muss man das nicht weiter verkomplizieren.
In der Praxis haben leider jegliche Dinge als echte Showstopper erwiesen, die die Auto-Updatefähigkeit von FF-Domains verschlechtern (z.B. weil Knoten nicht im zentralen Autoupdater laufen können, weil selbstgebriegene Anbauten).
Daher: Basteln gern, aber bitte nicht am FF-Gluon-Router selbst, sondern an Dingen, die dahinter hängen. Also ESP8266, oder noch ein alter 741er. Oder was mit ordentlich Flash (einige WR710er zB.), so dass man auch SSL hineinbekommt. (prinzipiell insbesondere für Aktoren sehr sinnvoll, zumal in einem zudem ziemlich offen Netz.)
Technisch ist das, was @heilbron vorhat, eine Bespitzelung von Freifunk-Nutzern; gerade in batman_adv-Netzen kann dies auf jedem Knoten umgesetzt werden, d. h. meshweit auch Bewegungsprofile einzelner Geräte erstellt. In anders strukturierten Netzen mag das weniger einfach möglich sein, grundsätzlich halte ich solche Auswertungen für nicht mit dem Gedanken eines freien Netzes vereinbar — Spieltrieb hin oder her.
Also, ich habe den Eindruck, das jemand Bestimmtes hier auf einem komischen Trip ist: Erst die Äußerung eines Anderen im Forum als „Bullensch…e“ zu bezeichen, im gleichen Post zwei Zeilen später Tipps zur Internet-Erziehung zu geben - welche unbeabsichtigte Ironie … Dann noch die „abschaltbare Datenautomatik“ vieler Tarife nicht kennen. Und jetzt noch: das Ein-/undAusloggen ganz ausgewählter (nochmal für Schnelleser oben schon extra fettgedruckt!) Smartphones (mit der Layer2-Adresse) auf einem einzelnen Routen als „Bespitzelung“ zu bezeichnen… ohne weitere Worte…
Danke an alle anderen, die faktisch argumentiert haben! Das mit der Upgradefestigkeit leuchtet ein, gerade deswegen wollte ich ja möglichst wenig (optimalerweise nichts) Zusätzliches installieren, sondern z.B. nur Firewallregeln ergänzen oder höchstens ein zusätzliches Skript installieren, das gerne hops gehen kann. (Im ungünstigsten Fall bleibe ich halt bei SSH-Skripten)
Zu meiner technischen Frage: Kennt also niemand eine Bibliothek, um von einem Raspi den respondd-Daemon zu befragen, oder vielleicht auch remote mit dem ubus zu kommunizieren?
Vorsícht, Du hast soeben § 186 StGB erfüllt. Lerne lesen, spart Geld. Ferner unterstellst Du mir wahrheitswidrig weitere Dinge, die Du nicht beweisen kannst. Ganz dünnes Eis.
Ich habe spaßeshalber grade mal auf einem meiner Knoten geguckt: lokal verbundene Endgeräte tauchen scheinbar ganz normal bei arp -an bzw. in /proc/net/arp auf, man kann das scheinbar also komplett lokal umsetzen, ohne Informationen aus dem Mesh zu nutzen. Damit entfällt das Problem des Trackings, was sich durch Nutzung der nodes.json oder batctl ergäbe. (respondd reagiert AFAIK nur auf Multicast-Anfragen im Mesh, was zu Antworten aller Knoten führen würde.)
Check’ mal /lib/upgrade/keep.d/base-files-essential auf Deinem Knoten, falls da /etc/rc.local drinsteht, solltest Du in /etc/rc.local Kram hinterlegen/starten können, was auch ein FW-Ugrade übersteht.
Bist Du denn selbst im Hauptberuf Richter, dass Du selbst genau so eine Tatsachenbehauptung aussprechen oder sogar entsprechend urteilen kannst? Und meinst Du wirklich ernsthaft, verständige Personen würden obige Texte entsprechend einschätzen? Und das es sich außerdem lohnt, „halböffentlich“ so zu schreiben…
Weil es hier aber ein Technikthread ist:
… lokal verbundene Endgeräte tauchen scheinbar ganz normal bei arp -an bzw. in /proc/net/arp auf, man kann das scheinbar also komplett lokal umsetzen, ohne Informationen aus dem Mesh zu nutzen.
Bei mir (gluon-v2018.2.3) zeigt /proc/net/arp nur die WAN-Seite:…
Und ja, /lib/upgrade/keep.d/base-files-essential enthält bei mir tatsächlich /etc/rc.local, aber das wollte ich ja gerade minimal halten, indem ich Infos vom respondd nutze und im Sinne von dem, was @anon68922371 oben sagt, versuche, upgradfest unterwegs zu sein.
… Dann noch die „abschaltbare Datenautomatik“ vieler Tarife nicht kennen. Und jetzt noch: das Ein-/undAusloggen ganz ausgewählter (nochmal für Schnelleser oben schon extra fettgedruckt!) Smartphones (mit der Layer2-Adresse) auf einem einzelnen Routen als „Bespitzelung“ zu bezeichnen… ohne weitere Worte…