kurze Zwischenfrage von mir: was liegt den bei euch allem im RAM drin?
edit –
Und mit Kernel Modulen meinte ich das ganze zeug wie USB Unterstützung und so dinge die im Kernel drin sein können ( evtl, gibt es ja auch einen minimal kernel für dass device)
edit end –
Wie denn? Wüsste jetzt nicht, wonach ich da suchen sollte. Gibts da schon eine Anleitung? Wo?
Auf welchen Beobachtungen fußt denn deine Erkenntnis, dass der RAM knapp sei, @rubo77? Wenn dem wirklich so wäre, würde der Knoten vermutlich abstürzen.
Wie @adorfer schon geschrieben hat, ist es völlig normal, dass ein 841N(D) mit 90%iger RAM-Belegung angezeigt wird. Das heißt aber nicht automatisch, dass der RAM knapp ist.
Bitte verwechselt nicht die zwei getrennten Themen der Entschlackung:
Bei knappen RAM hilft es NICHT, auf Pakete wie opkg zu verzichten oder diese nachträglich zu löschen.
Es würde allerdings z.B. helfen, Pakete/Programme zu deaktivieren oder nicht zu starten. Das könnte man zb mit den Webserver oder dem respondd machen. Dazu braucht man auch keine neue Firmware bauen.
FFRN hat sich mit dem Thema intensiver auseinander gesetzt: https://forum.ffrn.de/t/workaround-841n-load-neustart-problem/1167 - vielleicht helfen die Erkenntnisse die dort gesammelt wurden dem einen oder anderen.
Apropos haveged: Evtl könnte ein Patch in Gluon bzw fastd helfen (der recht trivial ist, und den ich vor einigen Monaten auch mal machen wollte, aber am fehlenden Testbed war es bei mir gescheitert)
Wie bereits verlinkt wurde, benötigt fastd nur einmal beim Start kurz ganz wenig Entropie, danach läuft alles über den eigenen Zufallsgenerator. Außerdem benötigt man Entropie, wenn Schlüssel generiert werden.
Dazu wird /dev/random aufgerufen, welches auf Linux blockiert, wenn ein „Entropie-Zähler“ auf 0 ist. Dieser Zähler wird erhöht, wenn Entropie aus Hardwarequellen hinzugefügt wird, und verringert, wenn Bits aus /dev/random gelesen werden. Auf den kleinen TP-Links ist nur wenig solche Hardware-Entropie pro Zeiteinheit verfügbar, also installiert man haveged welcher durch dunkle Magie aus der Programmausführung selbst Entropie gewinnt. So weit so gut.
Die Sache ist: Dieses Design ist eigentlich für quasi alle Anwendungszwecke unnötig, kryptographische Anwendungen explizit eingeschlossen. Sobald der Zufallsgenerator einmal ordentlich initialisiert ist, liefert er für immer kryptographisch sichere und unvorhersagbare Zufallszahlen. Man könnte in dem Fall auch von /dev/urandom lesen, welcher nicht blockiert.
Warum also /dev/random? Problem ist eben die Initialisierung. Normalerweise wird beim Shutdown ein wenig Entropie weggespeichert, um damit ganz früh im Bootprozess den Zufallsgenerator zu seeden. Das doofe ist nun bei unseren Freifunk-Kisten, dass wir nur Flash haben, den wir nicht kaputt schreiben wollen. Also müssen wir wohl oder übel /dev/random nutzen, wenn wir sicher gehen sollen, dass wir nicht aus einem uninitialisierten Zufallsgenerator lesen.
Oder? Eigentlich nicht. Denn ab Linux 3.17 gibt es einen neuen getrandom(2) Syscall. Dieser verhält sich exakt so wie /dev/urandom (liefert beliebig viel Entropie), mit der Ausnahme, dass er direkt nach dem Boot solange blockiert (d.h. den anfragenden Prozess „eingefroren“ lässt), bis er einmal ordentlich initialisiert ist.
Da Gluon bereits auf Kernel 4.x ist, würde es ggf. helfen alle Aufrufe von /dev/random durch Aufrufe von syscall(SYS_getrandom) zu ersetzen. Der Patch ist ziemlich einfach, müsste nur mal wer™ machen.
Mach dazu im gluon Git mal ein issue auf.
blöderweise ist debian stable noch bei 3.16. Ob man da die Kompatibilität aufgeben will?
Problem: Die Entropie-Sammlung des Kernels ist auf MIPS ohne haveged ziemlich wirkungslos. Die Initialisierung dauert häufig mehrere Minuten, und selbst wenn der Kernel glaubt, dass er genug Entropie hat, ist das auf diesen Embedded-Kisten häufig einfach falsch (zumindest war das vor einigen Jahren der Fall, zu Zeiten von Attitude Adjustment). Wir haben damals schon aus /dev/random (!!!) auf 2 Knoten identische fastd-Keys gezogen, bevor wir haveged in die Firmware aufgenommen haben…
Wir brauchen das ja nur für fastd. könnte man hier nicht schummeln und entropy as a service nutzen? Dann bräuchte man nur: ~pollinate/pollinate/trunk : contents of pollinate at revision 375
und nutzt https://entropy.ubuntu.com/
ffrn-lowmem-patches kennst Du? Das macht genau das:
# only do something if less than 40megs of RAM
RAMSIZE=`grep MemTotal /proc/meminfo | awk '{print $2}'`
if [ $RAMSIZE -le 40000 ] ; then
# start haveged in config mode
MODE=`uci get gluon-setup-mode.@setup_mode[0].enabled`
if [ $MODE == "1" ] ; then
/etc/init.d/haveged start
fi
# disable and stop haveged if enabled
if [ -f /etc/rc.d/S13haveged ] ; then
/etc/init.d/haveged disable
/etc/init.d/haveged stop
fi
[…]
Was hat Gluon mit Debian zu tun?
sieht gut aus, allerdings ist da ein offener Pull Request, der fatal aussieht, wenn der nicht angenommen wird, oder sehe ich das falsch?
Das müsste @nazco mal anschauen. Auch wäre ein README dort sehr schön das erklärt, was die sysctl Befehle alle bewirken
link? sehe da keinen offenen.
viele Gatways nutzen debian. Wenn fastd dort nicht mehr mit dem Kernel zurechtkommt, wird das auch ein gluon-Thema (sofern es wirklich bei einer simplen Ersetzung bleibt und keinen fallback gibt).
ob es fatal ist PRs nicht anzunehmen ist glaub ich auch so eine Sache. Manchmal ist ein bisschen weniger laut besser. 
Und dann wäre da noch die Frage an neoraider: die Tests kommen aus der AA-Zeit. Meinst Du die sind jetzt noch gültig oder müsste jemand ™ das mal wiederholen?
PS: ich sehe gerade dass alle diese Punkte als Antwort an wusel gingen. Nur der erste war als direkte Antwort gedacht. Umgang mit dem Forum krieg ich auch irgendwann noch hin…
[quote=„Klaus_Dieter, post:22, topic:14863“]
viele Gatways nutzen debian.[/quote]
Und Millionen Fliegen können nicht irren: Scheiße schmeckt.
Beide Aussagen haben eines gemeinsam: mit fastd auf dem Knoten und wie fastd dort an »Zufall« herankommt, haben sie nichts zu tun.
Davon ab, Jessie kennt via Backports auch 4er Kernel, aber, nochmal: für fastd als Userspace-Anwendung ist die Version des Linux-Kernels egal (zumindest für Majors von 3 bis 5).
Und manchmal ist erst informieren, dann rumlabern, wirklich ein guter Ratschlag: in ffrn-lowmem-patches schlummerte in der Tat ein fieser Bug, wie auch im Dezember im dortigen Forum erkannt. Schön, daß er am 30.04. per Annahme des PR gefixt wurde (daher fand @rotanid keinen offenen PR mehr) und dank an @anon68922371 für den Hinweis. (Ich stehe ja auf gut abgehangene Software; daß das Problem im Dezember zwar erkannt, aber im Code noch nicht gefixt wurde, habe ich im Eifer des Gefechts bei der Übernahme auch übersehen 
Nunja, wurde so mein erster cherry-pick ;))
Vielleicht sollte der Titel auf »Strategien für eine Gluon-v2016.2-Firmware, die gut mit wenig RAM auskommt« geändert werden (in Anlehnung an Beitrag #3)? Denn, wie schon diskutiert, 4 MB Flash sind sehr knapp, aber im laufenden Betrieb schmerzt eher das kleine RAM.
Ja, ist Ok. Du hast recht und ich meine Ruhe. Das nicht mergen von bits in einem ff Projekt ist fatal, es können Menschen sterben. Abhängigkeiten von User space zu kernel existieren nicht, auch wenn Interfaces genutzt werden, die nicht in allen Kernels angeboten werden.
Das kann man natürlich so schreiben, dass es auch auf alten Kernels funktioniert und da auf /dev/random zurückfällt. Braucht man allein schon damit man nicht an Linux gebunden ist…
Aber mit der Anmerkung von Neoraider, dass die Linux-Entropieasammlung auf der Architektur ein bisschen buggy ist, hat sich das ja eh erledigt.
Die Antworten dort entsprechen ja im Fazit dem, was wir hier auch schon diskutiert haben.
Es gibt derzeit bei keinem Router ein Ram-Problem, was mit Verzicht auf einzelne Systemteile gelöst werden kann.
Die bei großen Domains auftretendenden Probeleme sind damit nicht zu lösen.
Entweder (mindestens) ein neuerer Batman und/oder ein 4er-Kernel. Oder gleich ein besseres Protokoll.
Nach einer Unterhaltung in #gluon mit @anon75826926 stellte sich raus: Es ist eigentlich nicht so gedacht, dass die RAM-Auslastung auf der Karte Buffer und Cache beinhaltet, denn beide Werte werden auf der Statusseite des Knotens herausgerechnet. Ist ja auch sinnvoller, die Werte herauszurechnen, weil der Kernel den freien RAM natürlich zum Cachen und Buffern nutzt, wie hier schon angeführt wurde, sodass die Auslastung dann immer recht nah am oberen Ende des insgesamt verfügbaren RAMs ist.
Der HopGlass-Server rechnet die Werte derzeit jedoch nicht heraus, sodass die Auslastung auf der Karte bei Communities, die den HopGlass-Server nutzen, immer höher angezeigt wird, als sie eigentlich ist.
Edit: Pull-Request erstellt, der diesen Umstand behebt