Strategien für eine Gluon-v2016.2-Firmware, die gut mit wenig RAM auskommt

Technik
1

Gibt es eine einfache Möglichkeit auf einem Router mit nur 4MB, der sehr stark frequentiert ist und daher oft den Speicher überfüllt dort platz zu schaffen?

Mir fällt da ein, einfach die opkg-module zu entfernen, wie könnte man das auf der Konsole machen?

Oder muss man da extra eine Firmware bauen, die die nicht enthält? Wenn ja, wie? es gibt ja dort kein opkg-Paket, das man in der site.mk einfach weglassen könnte, oder?

(im gluon master branch mit LEDE ist dies ja auch die lösung für die kleinen Router)

Eine Idee wäre einfach

opkg remove --autoremove opkg

:smile:

2

Der Zusammenhang zwischen „Rom voll, weil Router 'stark frequentiert“ erschließt sich mir nicht.

Das kann man allenfalls auf der Konsole der Build-Umgebung machen.
Auf dem laufenden System hast Du -außer mit extremsten Verrenkungen und evtl. einer Speichernachrüstung- keine Chance, das boofs zu verkleinern.

Dir ist schon klar, dass alles was Du ändert in einem overlay-FS landet, was faktisch nur „Delta“ zum eigentlichen (gepackten) FS ist?
d.h. es wird nichts gelöscht, es kommen nur Einträge dazu, die besagen _ „das da vorn nicht mehr anzeigen, sondern stattdessen diese neue Datei. Oder gar keine Datei mehr“_

Sprich: Es spart nichts, es braucht sogar noch mehr.

1 „Gefällt mir“
3

OK, anders gefragt: wie können wir in Freifunk Nord unter 2016.2.x eine Firmware bauen, die gut mit weniger Speicher auskommt?

unsere site sieht so aus:

    gluon-mesh-batman-adv-14    
    gluon-alfred    
    gluon-respondd    
    gluon-autoupdater    
    gluon-setup-mode    
    gluon-config-mode-core    
    gluon-config-mode-autoupdater    
    gluon-config-mode-mesh-vpn    
    gluon-ebtables-filter-multicast    
    gluon-ebtables-filter-ra-dhcp    
    gluon-luci-admin    
    gluon-luci-autoupdater    
    gluon-luci-portconfig    
    gluon-luci-private-wifi    
    gluon-luci-wifi-config    
    gluon-mesh-vpn-fastd    
    gluon-radvd    
    gluon-status-page    
    iwinfo    
    iptables    
    haveged
(die weiteren, eigenen pakete sind mini klein)

EIn Vorschlag war schon mal gluon-respondd zu entfernen (Solange wir das auf unserer Karte sowieso noch nicht nutzen können.)

4

Hallo rubo,

ihr könnte die Firmware auch entschlacken indem ihr nicht benötigte Kernel Module entfernt wenn das bei euch geht.

5

Ja genau, das war die idee. Welche brauchen wir denn nicht? Geht das nur über die site.mk? Oder braucht man da einen andern Trick beim Bauen?

OPKG findet man ja nicht in der site.mk, wie entfernt man das beim Bauen?

6

man könnte ja auch haveged entfernen:

Fortsetzung der Diskussion von Entropie=Wahnsinn=haveged wozu?:

  1. haveged wird nur fuer den ersten Boot bzw. im Configmode fuer die Generierung der Keys fuer fastd und ssh benoetigt.
  1. haveged braucht im Betrieb ca. 800kB RAM und es ist im Moment kein RAM-Mangel bekannt, auch beim Meshen nicht.

ist das immer noch so? Also auf unseren 4MB routern mit 32MB RAM ist meinst so 90% voll. da klingt mir 5% schon viel.

Soweit meine erfahrungen mit haveged ist es da so, dass ohne dieses Modul das generieren eines keys auf einem langsamen Rechner mehrere Minuten dauern kann, das könnte auf den Routern ja auch so sein, dann sollte man das besser nicht entfernen.

7

Du könntest natürlich zu kreativen Maßnahmen greifen, das factory image mit haveged, das sysupgrade ohne.
Zu Problemen führt dies dann eben wenn jemand bei einem bestehenden Router ein neuen fastd key benötigt, weil er beispielsweise einen factory reset durchgeführt hat.

8

Das ist eher eine religiös zu führende Debatte um buffer/RAM-Nutzung.
(Das kann man bei Linux-Kerneln genauso betreiben wie bei Windows 95 früher…)

Aber im Ernst: Woran machst Du „Ram ist knapp“ fest? Ja, Domains mit mehr als 500 Nodes haben Probleme. Aber das löst man nicht durch mehr Ram in den Routern, sondern durch einen Netsplit, Hood-Selector oder zukünftig mal Babel.
Denn der Background-Traffic zieht alle Leute mit nur 1MBit/s Upstream ins Verderben. (ja, auch wenn der Background-Traffic auf dem Papier nur 180kBit/s hat… die Packet-Rate ist das Problem.)

Ansonsten: Compiliere doch ohne OPKG, das geht doch problemlos.

1 „Gefällt mir“
9

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 –

10

Wie denn? Wüsste jetzt nicht, wonach ich da suchen sollte. Gibts da schon eine Anleitung? Wo?

11

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.

1 „Gefällt mir“
12

Bitte verwechselt nicht die zwei getrennten Themen der Entschlackung:

  • RAM (Arbeitsspeicher)
  • Flash-Speicher (wo die Firmware liegt)

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.

2 „Gefällt mir“
13

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.

1 „Gefällt mir“
14

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.

4 „Gefällt mir“
15

Mach dazu im gluon Git mal ein issue auf.

16

blöderweise ist debian stable noch bei 3.16. Ob man da die Kompatibilität aufgeben will?

17

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…

6 „Gefällt mir“
18

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/

19

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?

1 „Gefällt mir“
20

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