Fortsetzung der Diskussion von Openwrt auf JHR-N805R:
Anlässlich „was man alles herauswerfen kann aus dem Openwrt“ gab es von den Freifunkenden in Weimar einen Talk auf dem 35C3:
Einige Dinge davon sind ziemlich radikal. Aber wenn die Alternative ist „Geräte wegwerfen“, dann muss man sich halt überlegen, auf was man verzichten kann, um ein wieder (für den Anwendungszweck) gut nutzbares Gerät zu bekommen.
Die Slides gibt es https://pretalx.35c3oio.freifunk.space/media/freifunk-4mb.pdf
Klingt als sei noch deutlich Luft nach oben. Aber alles bringt einen nicht weiter, wenn der Fehler im Squashfs mit dem Cachingproblem nicht gelöst wird.
Und es bezieht sich alles auf die 4 MB Flash. Das Hauptproblem sind doch die 32 MB RAM.
Ich habe es so verstanden, dass
CONFIG_TARGET_SQUASHFS_BLOCK_SIZE=1024
CONFIG_KERNEL_SQUASHFS_FRAGMENT_CACHE_SIZE=1
das schonmal wesentlich entspannt.
Ah, hatte ich nicht mitbekommen. Danke.
Ist das im aktuellen Gluon schon drin?
Ersteres afaik ja, zweites nicht.
Langfristig bringt nur die Aufrüstung was. Die SquashFS-Blockgröße zu ändern, bringt meiner Erfahrung nach bei Gluon kaum etwas (an Speichereinsparungen), da tatsächlich so viele Daten in Nutzung sind.
Bei der Änderung der SquashFS-Blockgröße geht es auch garnicht darum, RAM einzusparen, sondern darum, die Blöcke zu verkleinern, damit das Thrashing-Problem nicht so massiv auftritt, weil es länger dauern würde, einen großen Block zu dekomprimieren. Die Annahme war nämlich, dass der Router häufiger große Blöcke dekomprimiert, obwohl er nur ein paar Byte davon benötigt.
Hat in meinen Tests alles bisher nicht den gewünschten Erfolg gebracht.
Vielleicht haben wir ja doch noch einen bösen Bug, der auch für das OOM bei vielen Clients verantwortlich ist und wir haben eigentlich mehr Luft, als wir glauben.
Dafür muss ich jetzt erst einmal aus dem SLUB-Tracing ein SLUB-Profiling bauen, das auf den KIsten läuft. Denn das ganze ist nicht für Embedded-Systeme ausgelegt, die eine serielle Kernelkonsole haben und kann auch nicht profilen. Leider habe ich überhaupt keine Zeit dafür. Ich muss mich gerade aufs Brötchenverdienen konzentrieren. Scheiß Kapitalismus…
Ich bin ja kein Programmierer und von daher bitte meine Anmerkungen entsprechend werten.
Wenn früher ™ ein funktionierendes Freifunk-Device mit 4/32MB doch funktioniert hat, warum kann man die Freifunksoftware „von heute“ nicht auch darauf abstimmen, mit eben diesen Ressourcen auch zum laufen zu bringen?
Ich ziehe mal einen (hinkenden) Vergleich: Ein VW Golf von 2000 oder 1990 fuhr, hatte ABS, war bequem, hatte aber keine elektrische Parkbremse oder elektrische Sitzverstellung.
Was ist alles in den letzten Jahren bei Freifunk-Software hinzugekommen, was zwar nützlich aber nicht unbedingt erforderlich ist und mehr braucht, als 4/32MB Ressource?
Es gibt sicherlich Nützliches in der Freifunk-Software, aber was kann man denn wirklich (wieder) rausnehmen? Denn tausende 4/32MB-Router, die draußen ihren Dienst verrichten, sollten es weiter tun können, auch wenn der technische Fortschritt heutzutage eher bessere Geräte bevorzugt und man supersteinalte Geräte irgendwann mal außen vor läßt. Nen 841er ist aber noch ein akzeptables Gerät in der freien WLAN-Wildbahn.
Weil die Ressourcen vorher schon knapp waren (4096 Kilobyte sind gar nicht mal soviel …) und – um in Deinem Beispiel zu bleiben – die gesetzlich vorgeschriebenen Sicherheitsnachrüstungen den Motor samt Anbauten so groß gemacht haben, daß der Motor- in den Fahrgastraum erweitert werden müßte — so richtig mit Flex und so.
Und die Hardware hat sich in der freien Wildbahn auch als gar nicht soo leistungsfähig herausgestellt, als daß man die 15€-Geräte auf Biegen und Brechen in Betrieb halten müßte.
Es hindert Dich oder andere niemand, die Firmware noch weiter anzupassen, um die durch’s Wachstum des Kernels zusätzlich belegten Blöcke des 4 MB kleinen Flash-Speichers woanders einzusparen. Da geht noch einiges, Web- und SSH-Server sind entbehrlich, auch DHCP braucht ein Freifunkknoten nicht zwingend – kann man alles fix in die Firmware einbauen, notfalls halt 1 Firmware-Image pro Gerät. Hat nur keiner Bock drauf, da es bessere Hardware gibt, die den Freiwilligen mehr bietet …
In den letzten Jahren ist auch einfach die jeweils vor Ort verfügbare Internetgeschwindigkeit nicht unerheblich gestiegen.
Zwar fährt der VW Golf heute noch. Aber, um in der Analogie zu bleiben (auch wenn es nicht ganz zutrifft), man erwartet heute einfach eine bessere Performance und das man schneller am Ziel ankommt.
Wenn der Router damals irgendwie funktionierte, dann tut er das heute vermutlich auch noch. Aber „damals“ merkte man nicht so sehr das der Router bei 100% läuft, da einfach viele Internetanschlüsse ziemlich langsam und einfach nicht performant waren.
Und die 841er irgendwann fallen zu lassen hat halt den Vorteil, das Freifunk nicht das vermutlich eh schon vorhandene Image eines grottenlangsamen und schlecht funktionierenden „Hotspots“ bekommt. Und (meine Meinung) man muss halt ein vernünftig performendes Netz haben, damit Leute die Router nutzten und selber aufstellen. Weil nur wegen der Netzneutralität und um ein lokales Mesh zu haben stellt sich vermutlich keiner einen Router auf.
Danke für Eure Antworten.
Ok, die Ressourcen waren schon immer knapp bei den kleinen 4/32MB-Routern (841er).
Ich habe verstanden, dass der Kernel mehr Platz als früher braucht, weil Sicherheits- und Performance-Code mit hinzukommen musste.
„Auf Biegen und Brechen:“ Naja, der 841er ist m.W. der am Breitesten verwendete ff-Router in ganz Deutschland. Wenn nun in absehbarer Zeit die zusätzlich erforderlichen Codezeilen dazu führen, dass diese 841er deutschlandweit hinten runterfallen, hm, wäre aus meiner Sicht für den Freifunk und seine Verbreitung nicht förderlich. Meine Meinung, muss man nicht teilen.
Welche der Dienste (Web/SSH/DHCP) dann rausfallen müssten, um sie zu halten, kann ich wirklich nicht beurteilen.
Internetgeschwindigkeit bzw. 100%-Auslastung: Also ich beobachte „unsere“ (ffks) 841er-Router hier in Kassel via Grafana schon öfter und lange, da ich diverse ffks-Installationen selber monitore. Es erscheint mir mitnichten so, dass da eine Menge oder sehr viele der 841er an der 100%-Grenze kratzen, auch wenn dort mal 10-30 Clients eingebucht sind. Andere Communitys kann ich nicht beurteilen, man möge mich korrigieren.
Selbst bei gestiegener Internetgeschwindigkeit (z.B. 10-16 MBit/s statt 2-6 MBit/s-Anschlüsse) scheint es da keine nennenswerten Probleme zu geben.
Und selbst wenn da 50 MBit/s-Anschlüsse für den ffks-Gateway-VPN-Tunnel genutzt werden, nun erwartet nicht jeder ffks-Nutzer heute gleich für sich selber 10, 20 oder mehr MBit/s.
Kurz: Wer mit seinem (mobilen) Client kostenfrei in der Stadt unterwegs „freies Internet“ in schon jetzt akzeptabler Geschwindigkeit nutzen kann und darf, wird sich nicht beklagen oder abwenden, wenn die Geschwindigkeit stagniert. Ist schließlich kostenfrei und funktioniert. (Auch meine Meinung - muss man nicht teilen)
<tl;dr> Zusammenfassend (aber ich kann eben nicht programmieren und nennenswert dazu beitragen): Ich hätte den Wunsch, die 841er weiterhin funktional zu halten, auch wenn neue Gluon/Firmware-Releases/Updates kommen.
Fallen 841er raus, verliert m.E. der Freifunk zuviel.
LG Jörg
Nunja, ‚wahre‘ Freifunker können sich da helfen; für reine ‚Hotspot-Knoten‘ macht nach n Jahren eine Hardwareauffrischung, insbes. mit Dualband, Sinn. IMHO, YMMV.
Wie ist denn die Performance bei >15/>25 Clients? 50 Clients seh’ ich an bestimmten 841ern (bzw. generell 4/32er Kisten) öfter — nutzbar ist da dann aber leider nix 
Arbeitstheorie ist derzeit, daß diese Geräteklasse mit der Last nicht klarkommt …
aktuell ist es ja auch noch nicht unmöglich, solche Geräte zu benutzen, insbesondere nicht in segmentierten Netzen.
Das heißt mit dem derzeit aktuellen Gluon (und auch dem kürzlich erscheinenden), beide auf Basis von OpenWrt 18.06, wird es noch ca. 1 Jahr mindestens weitergehen können „as usual“.
Es ist aber eben absehbar, dass es nicht mehr möglich sein wird, mit aktueller „Standardfirmware“:
→ Daher wird (frühzeitig) gewarnt.
Das heißt im ersten Schritt auch nicht, dass es gar nicht mehr geht, nur dass abgespeckt werden muss und nicht mehr 20 Pakete auf die kleinen Geräte mit draufgepackt werden können, sondern nur noch das allernötigste.
Das trifft voraussichtlich dann OpenWrt 19.07 und darauf aufbauende Gluon-Versionen - zumindest bin ich vorsichtig optimistisch, dass wir an diesem Punkt noch nicht auf das Grauen des folgenden Absatzes stoßen, sondern erst danach.
Danach kommen aber bald Hürden, die ehrenamtliche Freifunker nicht lösen können - bitte unterstellt niemandem bösen Willen!
Wenn ihr also viel freie Zeit und viel Ahnung von Kernel, OpenWrt und Co. habt, seid ihr herzlich Willkommen die bestehenden OpenWrt Branches jahrelang weiter zu supporten, indem ihr die nötigen Security Patches darauf zurückportiert - was zuvor natürlich bedingt, dass ihr auch andauernd prüft, ob es neue relevante Patches gibt, die man zurückportieren müsste. (backport).
Solange es so jemanden nicht gibt, bleibt Gluon und den Communities nichts anderes übrig als irgendwann schwache Geräte „rauszuwerfen“ um zumindest für die übrigen die Sicherheit gewährleisten zu können.
By the way, dass mit dem OpenWrt-Release nach 19.07 Probleme kommen liegt nicht nur am Speicherplatz, sondern auch daran, dass OpenWrt das target ar71xx auf ath79 umstellt. Das bedeutet, dass jedes Gerät neu in OpenWrt eingepflegt werden muss im neuen Target ath79. Dazu benötigt man wiederum Zeit, Wissen, Lust und alle betroffenen Geräte in der Hand.
‚Wahre‘ Freifunker gibt es in allen möglichen Abstufungen - vom Hightech-Hardware/Software-Entwickler bis zum Klinke-putzen-Null-Technik-Versteher-Router-Aufsteller. Der Letztere kann sich nur bedingt selber helfen, außer nen neues Gerät kaufen und ff-flashen.
Och, die 841er-Geräte, die ich so monitore, kommen mit der Last bei 10-30 Clients gut klar, wenn nicht jeder von denen Netflix guckt 
50 Clients an 841ern kommt auch vor, ja, aber da muss dann halt nen performanteres Gerät aufgestellt werden, da sind wir uns einig.
Ok, das wusste ich so nicht. Das setzt natürlich wieder Einarbeitung und entsprechende Lust bei den Entwicklern voraus.
Nun gut, für mich wäre halt der Erhalt der 841er-Infrastruktur nach Möglichkeit toll, aber wenn es so nicht geht, dann ist das halt so.
Schönen Dank für die gute Diskussion und Grüße von der Ostsee (plätscher) 
Stand heute (bis zu Gluon 2018.2.x also) ist es ja möglich, „man“ muß „nur“ das Target ar71xx-tiny mitbauen, dann fallen da auch Images für 4/32er-Boxen raus (ist ja schon länger so, seit Gluon v2017 IIRC). Was die Zukunft bringt? Eher keine Firmware für 4/32er-Geräte, das sollte man antizipieren, akzeptieren sowie kommunizieren.
Sofern sich grundlegende Netzparameter nicht ändern, können ja aber auch ganz alte Firmwares noch mitspielen … Und wenn man die Mittel hat (z. B. entspr. ausgestatteten Hack-/Makerspace o. ä.), kann man ja auch die Hardwarenachrüstung ins Auge fassen (siehe anderer Thread).
Zunächst einmal geht es darum, die 4/32er-Geräte heute wieder in einen Zustand zu bekommen, in denen sie kein Potential verschenken.
(Egal ob es nun darum geht, dass eine Community große L2-Domains hat, oder zu viele IPv6-Gateways, oder zu viele Batman-Gateways, oder zu viele Wifimesh-Routen, was alles früher oder später da zu führt, dass den Knoten das Ram ausgeht beim Versuch die expoentiell wachsenden Routing-Tabellen des Batmans zu reorganisieren im Betrieb)
Und das funktioniert mit den von den Weimarern vorgezeichneten Wegen.
(dieser Thread soll explizit nicht der x-te „Zukunft der 4/32er-Geräte“ sein, sondern draum gehen, was man konkret heute machen kann.)
Kleine Info: 19.07 wird der letzte Release für 4/32. Danach wird es eine Weile noch weiter gehen mit source only, falls sich jemand die Mühe macht die betroffenen Geräte zu pflegen.
https://openwrt.org/inbox/infobox/432_infobox_new#new_infoboxes
Mal eine andere Idee:
Wie wäre es, wenn man das ar71xx-tiny mit einem älteren Kernel aus 2016er Zeiten ausstattet? Damals lief ja noch alles tutti. Irgendwas länger gepflegtes, LTS mäßiges.
Ich könnte mir z. B. vorstellen, dass man das Geld, was wir damals zur Behebung des Bugs dafür einsetzen könnten, den älteren Kernel in einen Zweig oder einen Fork von Gluon zu bringen, mit dem die Geräte dann noch ein paar Jahre stabil laufen.
Und wer übernimmt das backporten von Sicherheitspatches, BATMAN etc?
In der Zeit ändern sich ja auch Kernelmodulschnittstellen etc…
Nun bei LTS sind Sicherheitsupdates ja dabei. Das lässt aber den Kernel auch wachsen…
Nutzvoll wäre eher eine Art Kampagne, dass die Knoten von den Betreiber nach und nach ersetzt werden. Gerade wenn ich sehe wie viel 841v9 teilweise verbaut sind… Nach den Jahren ist doch sicherlich ein anderes Gerät drin?
Freifunk ist eine gemeinsame Infrastruktur. Diese gehört zwischendurch mal „erneuert“. So wie die Straßen (in der Theorie) auch nach ne Weile neues Belag bekommen. Oder bei Strom neue Trassen gebaut oder erweitert werden weil der Verbrauch steigt.
Jeder wirkt mit. Auch der einsame Knotenbetreiber. Und da liegt der Fehler: aufstellen und vergessen. Die Mühen die dabei enstehen, Arbeitsstunden, Kosten und so weiter, werden nicht gesehen. So funktioniert das leider nicht. Und da haben wir alle irgendwo das freifunken teilweise falsch „verkauft“. Selbst ein Knoten ist nicht ganz befreit von Mühe und geringe Kosten. Egal ob Entwicklung der Firmware, oder weil Mustermann nach 5 Jahren sich neuer Knoten kaufen muss.