Das haben wir um 2016 sein gelassen, da dann durch mesh-only Knoten mal kein Manifest, mal kein Image gezogen werden konnte und Updates mehr so zufällig wurden.
hm, nie gehabt dieses Problem… vielleicht weil wir zusätzlich die IPv6-only IP drinstehen haben.
Ich bau’ das bei uns gerade mal durch, wird im Erfolgsfalle 'n gutes Stündchen dauern, sind leider nur 24 betagte Cores, und werde das spätetens morgen Nachmittag testen.
Die übliche lange Geschichte voller Mißverständnisse 
Sprich: Eigene Packages, die u. a. eine grundlegend andere Config-Mode-Philosphie umsetzen (Konfiguration über WAN als dhclient) und ein Geokoordinaten-zentriertes, geführtes Setup (erst Koordinaten angeben, damit Mesh vom Server bestimmt werden kann; dann syntaktisch richtige Mailadresse mit einer existierenden Mail-Domain angeben (ohne MX nix los), dann erst kann der Wizard beendet werden). Das ist alles nicht so ganz einfach, wenn man a) der OpenWrt-Entwicklung nicht folgt und b) von LuCI und Lua auf den Niveau eines 4-Wochen-VHS-Kurs-Besuchers Ahnung hat. 2018.2 ist seit Monaten bei uns in allem außer stable, scheint auch in der 841-Liga zu tun (wo 2017 IIRC ja eher so bääh war), und zu 2019.x scheint es kein wirkliches Manko zu haben.
Oder, ganz kurz: Stable ist 2016.2; wir wollen (müssen) ASAP auf was Neueres und dabei von fastd auf L2TP (WG dann als Trial) und von Compat 14 auf 15 (batman-adv 2013 auf 2018+). Bei einer 2018er Basis haben wir ein gutes Gefühl. Wegen der doppelten Änderung, und weil wir das nicht über den Firmwareserver steuern wollen, ist das fragliche Paket zwingend in funktional notwendig. Heißt, es wird erst ein Upgrade auf 2018.2 geben, und dann ein Update mit Domainsplit, Compat-Level-Upgrade und anderer VPN-Technik kurz hintendran.
Danach steht dann 2020.2 auf dem Plan, mit, als Ziel, weiterer Reduktion der Eingriffe in den Gluon-Basis-Code.
Was muss man dafür auf den Knoten installieren?
mit dem Knoten hat das nichts zu tun, deine Domain braucht A und AAAA DNS Einträge und der Webserver muss entsprechend über eine IPv4+IPv6 Adresse erreichbar sein.
Der Knoten kann dann im Fallback-Modus beides benutzen, da er in diesem Modus als DHCP-Client auch sowohl IPv4 als auch IPv6-Adresse hat, sofern das Netz zu dem er sich verbindet dies bereitstellt.
1 „Gefällt mir“
Hat $hier auf Anhieb (gegen den Münchner Testknoten; gegen die eigenen wird der Test nun wiederholt) funktioniert. Ich habe das aktuelle tecff-autoupdater-wifi-fallback-Package in unser Packages-Repo übernommen und mit dem statt ffho* die 2018.2-basierte FW neu gebaut.
Vielen Dank!