Ich fand die Idee von @yayachiken mit dem mobilen „Einsammel-Router“ eigentlich ganz gut 
.
1 „Gefällt mir“
Ich vermute das Problem ist durch meinen Versuch entstanden auch eine Version für den 841v10 zu bauen.
Ich mache jetzt das build-dir komplett neu und baue eine neue experimental.
Updates gibt es auch über die normale DSL Leitung, daher werden die Knoten falls sonst nichts vorliegt von alleine wieder eingefangen.
@monty hat leider recht, Freifunk Router ohne Mesh Link ziehen auch keine Updates über ihren vorhandenen direkten Internet Uplink:
root@ffac-first-node:~# autoupdater
wget: bad address '1.updates.freifunk-aachen.de'
There seems to have gone something wrong downloading the manifest from http://1.updates.freifunk-aachen.de/experimental/sysupgrade
wget: bad address '0.updates.freifunk-aachen.de'
There seems to have gone something wrong downloading the manifest from http://0.updates.freifunk-aachen.de/experimental/sysupgrade
No usable mirror found.
root@ffac-first-node:~# ping google.de
ping: bad address 'google.de'
root@ffac-first-node:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=53 time=5.738 ms
Es liegt daran dass überhaupt keine DNS Auflösung stattfindet, diese muss also manuell hinzugefügt werden:
echo 80.87.160.201 0.updates.freifunk-aachen.de >> /etc/hosts
Im Anschluss „autoupdater“ ausführen, eventuell mehrfach hintereinander bis er einen Versuch bei 0.updates.freifunk-aachen.de statt bei 1.updates.freifunk-aachen.de startet
Sorry dass dieser manuelle Eingriff notwendig ist.
Hi 
Was DNS angeht so gibt es zwei dnsmasq Instanzen, eine nutzt das Mesh (Default) und die andere nutzt den Wan Port.
Um den WAN Port DNS Server zu verwenden muss dieser explizit angegeben werden oder wenn dies nicht möglich ist via iptables owner module auf den anderen umgebogen werden.
Dies wird z.b. bei Fastd gemacht damit Fastd eben nicht den DNS Server im Mesh nutzt sondern am Wan-Port.
Der Autoupdater nutzt jedenfalls nur den Mesh DNS Server 
Oder den Autoupdater mit der Gruppe gluon-fastd starten, darauf prüft die Iptables-Regel:
start-stop-daemon -c root:gluon-fastd -S -x autoupdater -- -f
Schön ist das alles nicht.
Besser wäre beim Autoupdate der Versuch einer DNS-Auflösung auf :53 (Mesh), bei Nichterreichbarkeit auf :54 (WAN), und ggf. noch einen externen DNS-Server zu fragen.
Man könnte die IP-Adressen alternativ auch vor dem Autoupdate-Prozess bspw. per Script mit allen Fallbacks auflösen, nach /tmp/hosts/autoupdate schreiben und einen SIGHUP an den :53er-dnsmasq senden.
Ja das ist leider alles sehr unschön 
Als ich Tunneldigger als Fastd-Ersatz bebastelt habe, bin ich über dieses Problem gestolpert. Gut das start-stop-daemon mit dem Group-Flag kompiliert wurde
Bei Gluon wurde mein issue abgewiesen, mal sehen ob dort Überzeugungsarbeit fruchtet.
@moderatoren könnt ihr bitte alles ab Beitrag #24 in ein neues Thema „Autoupdate ohne Mesh“ in der Kategorie Gluon verschieben?
Sofern kein Nutzer der Experimental Version von Problemen zu berichten hat werde ich noch vor dem Wochenende das ganze als Beta Version ausrollen:
Wir fahren das Script (in der „ffnrw-version“) seit etwa 3 Wochen in Gelsenkirchen in der Stable und haben keine Seiteneffekte beobachten können.
PACKAGES_OFFLINESSID_REPO=GitHub - VfN-NRW/offline-ssid: Offline SSID-Script for Freifunk-Router
PACKAGES_OFFLINESSID_COMMIT=84255e76b05493b9021b72d046c8ef4d916365f8
Ich gehe davon aus, Eurer Script ist auch nach wie vor für das gluon 2012.1.2 und mag vermutlich nicht gegen ChaosCalmer-OpenWRT bauen wegen der neuen Interface-Namen, oder?
Wir hätten da bedarf wegen der 841v10er…
@MrMM die aktiven Checks machen ja auch nur einen Batman-adv ping. Sprich die prüfen nur nochmal aktiv ob das Problem möglicherweise nur kurzzeitiger Schluckauf war. 
Gefällt mir, das ihr die Idee aufgreift, sagt bescheid wenn ich noch irgendwo bei helfen kann.
LG Ruben