erfolgreich im Einsatz seit v2016.2.x, inzwischen v2017.1.8
erfordert aber einen Gluon-OpenWrt-Patch für das „iw connect“ Feature, der ggf. bei neueren Releases jeweils immer wieder neu angepasst werden muss - also kein triviales Package.
nein, ich bin nicht von Hochstift, aber mehr als das was in deren README steht hatten wir auch nicht zur Verfügung.
ja, nutzen wir, aber wie jemand schon schrieb, es gibt mehrere Varianten die sich stark unterscheiden.
Jedoch ist keine davon so kompliziert wie der fallback autoupdater
(Mesh-only-Knoten können dann wahlweise das Manifest oder das Image nicht ziehen und brechen ins Essen. Zudem klappte es so auch im NAT64-Netz noch immer nicht.)
Stelle ich die Frage mal anders: welche Community setzt ffho-autoupdater-wifi-fallback oder tecff-autoupdater-wifi-fallback (oder eine andere Version) denn mit Gluon v2018.2 oder später noch ein — und funktioniert es da?
(Der iw connect-Patch ist bei uns drin, v4 zieht sich der Knoten ja auch.)
in meinem tecff-autoupdater-wifi-fallback (fork von ffho) fand ich letzte Woche ein Locking Problem und stieß dann auch auf ähnliche Probleme wie du, als Beifang quasi. Vielleicht hat es mit dem Gluon Commit 01336f70ecc7ad1c0b4a3260a8b64ad8002540a6 zu tun?
Anyway, ich teste gerade Fixes die aktuell gut/fertig aussehen, danach werde ich mal auf unsere alten Firmwares zurückgehen um herauszufinden, seit wann es nicht mehr geht
Es könnte sein, dass meine Changes/Fixes alle auch mit älteren Gluon-Versionen bis hinab zu v2018.2.x funktionieren, ich werde das aber nicht testen, da kein Bedarf in meiner Community vorhanden ist, wir nutzen v2020.1.x/v2020.2.x
Der iw Patch ist übrigens nicht mehr notwendig seit Gluon v2018.2.x weil das „iw“ aus OpenWrt 18.06.x und 19.07.x den „connect“ Teil nicht mehr missen lässt.
Mein Held Ich hätte morgen sonst in die Runde gefragt, wer denn in den letzen 2 Jahren mal die Funktion des Packages überprüft hat …
tecff-autoupdater-wifi-fallback hatte ich ja vorher drin … Anyway, wenn Du weißt, woran’s liegt, guck ich mal anhand Deiner Commits, wie ich das für 2018 fluffig mache.
ich weiß nicht mehr wann ich zuletzt getestet habe, hole das diese Woche aber noch nach, denn es wäre ja schon wichtig zu wissen, seit wann es nicht mehr geht. Entsprechend bespielte Knoten haben dann ja diese Funktionalität nicht.
Ich meinte nicht meine Changes im Vergleich zu ffho, sondern meine Changes der letzten paar Tage! Die ich aber bisher nur auf einem Single-Band-Testgerät geprüft habe und auch bei uns noch nicht ausgerollt habe, erst zum Wochenende oder so dann auf experimental.
Ich weiß nicht ob bei dir das selbe Problem vorliegt, da ich nicht mit Gluon v2018.2.x getestet habe bisher. Das werde ich aber noch tun wie ich schon schrieb und auch was die Kompatibilität angeht äußerte ich mich ja schon vorsichtig optimistisch.
Ack; IIRC waren die diffs der beiden Trees auch minimal
Just FTR, mit deaktivierten ebtables auf dem Fallback-Mode-Knoten funktioniert’s auch nicht. Und da Telefone/Laptops v6 bekommen, kann’s eigentlich doch nur auf Seiten des WiFi-Fallback-Knotens liegen?
Zu 2018.2: Das soll unsere letzte 4/32-Version sein, und da hätte ich gerne den WiFi-Fallback-Mode funktional. (In unserer 2016.2.postrelease-stable tat er noch.)
warum 2018.2 ? bei uns laufen auch spätere Releases noch gut auf 4/32, und wenn es euch darum geht auf OpenWrt 18.06.x zu bleiben könntet ihr auch Gluon v2019.1.x benutzen, was wir bis Ende 2020 noch „supporten“ soweit möglich.
so, habe nun herausgefunden, dass das Problem mit „es geht nur IPv4“ bei uns auch bestand, jedoch für uns kein Problem war, da unsere Autoupdater-Server per dual-Stack erreichbar sind. Nebenbei haben wir aber auch einen IPv6-only Eintrag, siehe https://github.com/tecff/site-ffa/blob/stable/site.conf#L145-L147
In der aktuellsten Version unseres tecff-autoupdater-wifi-fallback (v5, commit 546f8585d575648d7e54febcebd2865307c7d03d ) ist dies aber behoben, IPv6 geht damit auch.
Das eigentliche Problem warum ich aufmerksam wurde war aber beim Locking und bestand seit commit 9d309cdf19b4280c3a0ea3bc7c150a2392317d39 (2018…) und ist nun auch gelöst.
Ich gehe weiterhin davon aus, dass man die Changes auch für ältere Gluon-Versionen bis v2018.2.x benutzen kann, wenn mir jemand das bestätigt durch Test, cherry-picke ich die Commits in unsere älteren Branches des tecff/gluon-packages Repo.