Naja, daß 4/32 zukunftslos ist, wird $hier schon seit Jahren kommuniziert. Rückblickend eher so, daß es nicht ernstgenommen werden kann …
Nächster Punkt: Du klingst so, als wäre das aktive Ausknipsen von z. B. 4/32-Geräten ein Kinderspiel (»wie dringend ihr die Geräte vom Netz nehmt«). Das ist es mitnichten. Beim Verbindungsaufbau sehen wir, AFAIK, genau nicht, was für ein Gerät da ankommt, entsprechend ist das Verhalten alles, aber nicht einfach.
Wir verlinken schon eine Weile keine Firmware für 4/32-Geräte mehr für neue Geräte, aber dass jemand hingeht und all die alten Geräte austauscht ist eine Illusion. Die werden weiterlaufen bis sie den Geist aufgeben. Zumindest bei uns gibt es niemanden der die Zeit und Nerven hätte, da allen Knotenbesitzern einzeln hinterherzutelefonieren und dann da hin zu fahren und die Geräte zu tauschen (mal abgesehen davon dass da auch kein Geld für da wäre).
Was es braucht ist eine gute Lösung für mixed-Firmware-Betrieb. Wenn wir 2022.1 ausrollen werden die alten, nicht mehr unterstützten Geräte das Update vermutlich einfach ignorieren. Soweit, so gut, aber wenn jetzt ein point-release für 2021.1 kommt oder wir etwas an der site.conf ändern müssen, wie bauen wir dann am besten noch „neue“ alte Firmware für die alten Geräte um diese da ausrollen zu können? Können wir die Firmware-Dateien verschiedener Gluon-Builds im selben autoupdater-Ordner „mischen“ oder gibt das Chaos weil die Manifeste sich gegenseitig überschreiben? Können wir irgendwie eine neue 2021.1-basierte FW bauen die die Firmware-Autoupdate-URL nur für diese nicht mehr unterstützten Geräte auf etwas anderes umschreibt damit wir da noch zukünftige 2021.1-basierte Updates ausliefern können?
Ähnlich $hier; zumindest wird factory nicht mehr gebaut, die Images liegen aber natürlich, schon für den Autoupdater, auf dem Firmwareserver.
… oder durch Infrastrukturänderungen abgehängt werden. Proaktiv abschalten, ggf. durch ein »Upgrade« auf OpenWrt, sowas ist $hier hicht geplant.
Das wirst Du mischen müssen; make manifest listet IIRC die gebauten Images, ob ein Versionsvergleich auf Dateiebene im autoupdater zusätzlich stattfindet, weiß ich gerade nicht.
Eine hiesige Überlegung ist ein legacy-Branch, in welchen alle ar71xx-tiny-Knoten zwansgweise geschoben werden, so oder ähnlich:
ifeq ($(GLUON_TARGET),ar71xx-tiny)
GLUON_SITE_PACKAGES += force_legacy_branch
endif
Ggf. die letzte 2021.2.x-Version nur für ar71xx-tiny mit dem Package bauen, die anderen Architekturen bekommen dann in stable & Co. 2022.x — so der grobe Plan bislang $hier. Aber wir stehen ja noch vor 2021 als nächstem Schritt 
Da 2021.1.x auf 19.07 basiert, welches Upstream bereits EOL ist, wird da nach einem wrap-up zeitgleich zum kommenden 2022.1.x wohl nichts mehr kommen.
meisnt du nicht 2022.1 ?
ich denke sowas werde ich auch machen.
2021.2.x gibt es nicht. und ar71xx-tiny reicht nicht, die 8/32 Geräte sind in ar71xx
seufz.
Stimmt, 2021 hatte nur .1; aber rausfallen tun doch „nur“ 4/32 aka ar71xx-tiny?
ar71xx wurde ja nun schon vor über einem Jahr gedroppt.
Die Wiederaufnahme von Geräten mit weniger als 64 MB RAM in ath79 wurde unter anderem auch nochmal beim letzten Gluon Meetup 2022/03 besprochen.
Dabei ist herausgekommen das die 8/32 Geräte aktuell mehr oder weniger im Kreis booten und sie so nicht aufgenommen werden können.
Die Auffassung der Anwesenden war das es zwar durchaus möglich wäre die Dinger nochmal in 2022.1 hineinzubekommen, es darüber hinaus aber wohl nicht mehr möglich sein wird die halbwegs stabil zum laufen zu bekommen.
Und bislang hat meines Wissens bislang niemand Interesse gezeigt da nun Zeit zu investieren.
https://github.com/freifunk-gluon/gluon/issues/2413#issuecomment-1155677388
https://github.com/freifunk-gluon/gluon/issues/2413#issuecomment-1173141227
Es wird also wohl voraussichtlich in Gluon 2022.1 kein Support für Geräte mit weniger als 64 MB RAM (und 8 MB Flash) enthalten sein.
Kontext? Mein Stand ist: ar71xx ist tot in OpenWrt 21, es lebe ath79?
Das generell Geräte unter 64 MB RAM in Gluon ab v2022 nicht mehr unterstützt würden, wäre mir neu?
Es wäre auf den ersten Blick jedenfalls kein überzeugendes Argument für Gluon v2022. Aber für Gluon v2022 scheint das ja zumindest noch vom Tisch zu sein:
Die Frage, die ich mir aus Anwendersicht da stelle, läuft ein bißchen auf den Monty-Python-Sketch hinaus: was hat Explosion des Platzverbrauchs den Gluon-Anwendern je gebracht?
Analysis of firmware size growth
As example, the size of the sysupgrade release image for WNDR3700v1, an ar71xx/ath79 device that has been supported by Openwrt for ten years:
master: 5056.3 KB (snapshot without LuCI) 21.02.0: 5248.1 KB 19.07.8: 4096.3 KB 18.06.8: 3712.0 KB 17.01.7: 3584.0 KB 15.05.1: 3584.0 KB 14.07: 3328.0 KB 12.09: 2816.0 KBMain reason is growth in size of the Linux kernel itself, but all included core packages (wifi, LuCI, etc.) also tend to grow as their features get expanded.
Es macht den Eindruck, daß ohne Mehrwert für den Einsatzzweck »Access Point« die Hardwareanforderungen immer schneller nach oben schnellen — und insofern mehr und mehr gar nicht mal so alte Hardware stumpf aus dem Support fällt.
Wieso wächst z. B. der Linux-Kernel so über alle Maßen, welchen Nutzen bietet es konkret für Gluon, aber auch für OpenWrt?
As the current stable 21.02 release uses kernel 5.4 that is roughly 0.5 MB larger than the kernel 4.14 used in the old 19.07.x releases
Sicherlich ist es keine Option, daß OpenWrt einen Linux-Kernel forkt und pflegt; aber welchen konkreten Nutzen haben OpenWrt-, welchen Gluon-Nutzer, aus den 0,5 MB mehr Kernelcode? Aber was kann man tun, diesen Platzbedarf wieder einzufangen, damit Linux auch für Embedded-Systeme eine valide Option bleibt?
das Protokoll hat er doch verlinkt?
du verwechselst hier 8/32 mit 8/64
du hast ja schon erkannt, dass es nicht an Gluon und nur teils an OpenWrt liegt und niemand die Möglichkeit hat den Linux-Kernel zu forken.
wenig, aber als winzige Zielgruppe hat man da keinen Einfluss
ist es. nur nicht für solche, die zum sparen von Cent-Beträgen unnötig spartanische Spezifikationen haben.
Und wenn du OpenWrt forkst um Kernel 4.14 weiterzubenutzen, kannst du noch bis Januar 2024 Updates bekommen.
Da kommt „64“ nicht vor.
Um eine getätigte Aussage angepaßt zu wiederholen: »es ist Aufgabe der Entwickler das schon seit „Jahren“ so dringend zu kommunizieren, dass an dieser Stelle niemand mehr enttäuscht sein kann, wenn sie den Support von heute auf morgen streichen würden«.
Das Ende von 4/32 wurde über Jahre kommuniziert. Schade, daß das mit den weiteren Restriktionen nicht auch geschehen ist.
Du hast „deine Spec vom letzten Jahr finden wir nicht mehr ausreichend“ falsch geschrieben.
Das ist nicht was du geschrieben hast. Es ist ziemlich genau das Gegenteil?
Der Autoupdater-Bug öffnet jedem, der im Netz ist und weiß, wie es sich auswirkt, dass wir super viel in Gluon auf Layer 2 machen, die Möglichkeit Knoten anzugreifen, ihre Firmware auszutauschen und gewährt damit direkten Zugriff auf die Knoten und das verbundene Heimnetz.
ach komm, langsam kommst du mir echt vor als trollst du absichtlich…
64 kommt natürlich nicht vor weil 64 niemand abschaffen will, soweit für dieses Jahre bekannt.
wenn man mir eine Glaskugel reiche, dann prophezeie ich alle künftigen Probleme.
Geräte mit 8/32 sind uralt, nicht von letztem Jahr.
Das ist eine Frage der Perspektive. OpenWrt hat upstream auch diverse Features des Kernels aktiviert, beispielsweise für ujail. Einige dieser maßnahmen hatte Gluon wieder deaktiviert, da wir mit dem Gluon package-set diese Features nicht nutzen.
Der Kernel-growth hält sich aber auch im Rahmen:
Kernel 4.14
uImage header, header size: 64 bytes, header CRC: 0x37E70A48, created: 2021-07-28 12:17:13, image size: 1701235 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0x9DF6610B, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-4.14.275"
Kernel 5.10
uImage header, header size: 64 bytes, header CRC: 0x8D17618, created: 2022-06-18 00:37:56, image size: 2194677 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0x87F844, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-5.10.120"
Das sind knapp 500kB in etwas unter 5 Jahren. Dazu kommt, dass 19.07 noch weniger Geräte insgesamt unterstützt hat, wodurch im Umkehrschluss auch weniger Optionen des Kernels aktiviert wurden.
Ich stelle den Vergleich nur an, um die Kirche wieder etwas zurück ins Dorf zu fahren. 8/64 und größer haben noch gute Jahre vor sich und sind nicht nächstes Jahr Elektroschrott 
Bei Geräten mit 32M Flash ist das Problem dies, dass wir zwar kein hartes Limit beim bauen erreichen (Image passt theoretisch in den Flash), der Autoupdater allerdings während des Downloads OOM läuft.
Nein ich meinte ein point-release für das alte Gluon, das man noch auf den tiny Geräten ausrollen wollen würde. Z.B. ein Sicherheitsfix der als kritisch genug für einen Backport angesehen wird, oder so.
Gibts da ein Gluon-Paket für? Das braucht ja nicht jede Community neu erfinden.
Können wir diesen Thread bitte darauf fokussieren, wie wir jetzt mit der Situation umgehen, dass Gluon 2022 einige weit verbreitete Geräte nicht mehr unterstützt? Es bringt doch nichts zum drölfzigsten mal dieselbe Diskussion abzuspulen darüber, warum der Support wegfällt oder was irgendwer hätte anders machen können oder so. Fakt ist die Leute die an Gluon arbeiten (unendlichen Dank dafür 
) haben beschlossen dass es den Support nicht mehr gibt – ich finde das so frustrierend wie du, und wenn ich Kunde dieser Firma wäre würde ich mich irgendwo beschweren, aber es gibt keine Firma und ich bin kein Kunde. Ich profitiere – wir alle profitieren – von der ehrenamtlichen Arbeit anderer. Konstruktiv gibt es also nur 2 Dinge zu tun:
In Hannover hatten wir 2019 unsagbar viele 841er. Nicht zuletzt, weil weite Teile unseres Kernteams das seit 2014 bei jeder Gelegenheit als günstiges Einsteigergerät angepriesen hat und TP-Link nicht aufgehört hat die Dinger in immer neuren Revisionen rauszubringen.
Entsprechend düster war die Perspektive, als sich abzeichnete, dass die Geräte ans Limit ihrer Belastbarkeit gelangen würden und wir auf einen Schlag mehr als die Hälfte unseres Netzes verlieren könnten, wenn der Support gedropt werden würde.
„Aber die sind ja noch gut“ ist auch dann noch ein Einstieg in diverse Diskussionen gewesen, als sich andere Communities schon darüber lustig machten, welche Communities die größten „Müllberge“ besitzen würden und darüber Tortendiagramme schufen.
Will sagen, da waren wir und haben erst spät in den Abbau dieser Altlasten investiert.
Mittlerweile konnten wir nicht nur etablieren, diese Geräte nicht mehr neu zu deployen, in dem wir alle Empfehlungen dahingehend mit dringendem Abraten markiert haben,
sondern konnten die Anzahl der Bestandsgeräte auch auf etwa 25% drücken.
Im wesentlichen waren das bei uns fünf Maßnahmen:
Kürzlich haben wir dann noch begonnen, im Meshviewer Router zu markieren, die keine Zukunft haben.
z.B. Freifunk Hannover - loading...
Wir haben (noch nicht) angefangen, die Besitzer proaktiv anzuschreiben. Werden das aber bald in Angriff nehmen. Andere Communities haben das in Skripten gelöst und alle bekannten Kontaktadressen angeschrieben.
Ich glaube nicht, dass sich bei uns so viel getan hätte, wenn wir das Ziel nicht kontinuierlich (mit schwankendem Aufwand) verfolgt hätten.
Freifunk München hat den meisten Rückgang der 841er erfahren, in dem wir die SSID aller Altgeräte auf „bitte-router-erneuern.ffmuc.net“ geändert haben obwohl wir schon seit 2019 informieren (Austausch älterer Router).
In den Grafen kann man die Abnahme seitdem stetig beobachten (Grafana). Leider haben wir weder Förderprogramme noch sahen wir das Aufrüsten als sinnvolle Alternative an. So blieben nur neue günstige Router und Aufklärung.
Wir haben lange evaluiert ob ein Fork eine Grundlage wäre, im Endefekt gibt es aber jetzt schon zu wenig die Firmware bauen können oder wollen, also ist es kein Weg der Substanz hat. Deswegen bleiben wir am Upstream.
quasi der zweit-drastischste Weg vor einer Aussperrung - Respekt für den Mumm zu so einer Aktion!
Sowas hatten wir auch mal drin, Anfang 2020, nach interner Diskussion wurde sich dagegen entschieden. Argumentationslinie war, IIRC, »sieht eh’ keiner« und »frißt Airtime«. Vielleicht als neue SSID auf EOL-Geräten — wenn’s nimmer tut, gucken (wenige) Leute tatsächlich mal in die SSID-Liste; das Gros merkt $hier im Zweifel nicht mal, daß (Freifunk-) WLAN grade nicht da ist.
EDIT: oh, also echt statt der normalen FF-SSID? Wir hatten das als 2. SSID nach Karlsruher Vorbild drin. Non-invasive, was aber auch eher non-functional im FF-Kontext bedeutet …
Jo, wir haben dass statt der normalen SSID gemacht, weil sonst hätte es bestimmt niemand gesehen :). Die Funktion bleibt dabei erhalten.
Mal sehen, wann wir die einbauen.
Denke mit der kommenden Version, in der wir endlich auf WireGuard migrieren