dd und Pipes bedarf iflag=fullblock
Nur dann, wenn die Eingabedatei ihrerseits ein EOF mitten in einen (partiell gelesenen) Block signalisieren kann, was hier durch das Einbinden von "/dev/zero" als letzte Quelle definitiv nicht der Fall sein kann.
Das "cat" davor hämmert die Daten einfach der Reihe nach in Richtung STDOUT (selbst wenn beim Übergang zwischen den drei Quellen irgendwo mal keine Blockgrenze erreicht werden sollte) und jeder einzelne Read-Request des "dd" kann
immer einen vollen Block (von 256 Byte Länge) lesen, solange "/dev/zero" nicht blockiert, was ich noch nie gehört/gelesen habe.
@hermann72pb:
Wenn das Image ohne den Vector funktioniert (das sollte man mit dem Gerät testen, indem mal alle denkbaren "Hardware"-Funktionen, die einen NMI auslösen könnten - bis hin zum Reboot, was auch durch so einen NMI ausgelöst werden
könnte - genau testet oder sich die Struktur der originalen AVM-Firmware hinsichtlich des SquashFS-Images doch noch mal genauer ansieht), dann hat sich das Thema ja erledigt ... mich irritierte eben nur die eher ungewöhnliche Größe, wenn das SquashFS-Image wirklich schon davor komplett ist und da ich mich selbst dann immer nur "step by step" vom Original entferne, hätte ich das halt in das eigene Image übetragen (so es wirklich relevant ist und die Daten nicht doch zum SquashFS-.Image gehören).
Funktioniert das auch so, vergiß das Thema "NMI Boot Vector" einfach wieder.
@er13:
Inzwischen hat sich die Welt auch weitergedreht und es gibt neben neuen Browsern (das FRITZ!Box-GUI selbst braucht ja auch mind. HTML5-Support) auch neue Technologien, z.B. WebSockets (auch wenn der vielgerühmte "websocketd" ein Go-Programm ist und damit für die FRITZ!Box wohl keine Alternative).
Es gibt aber mit "
Xterm.js" einen ganz netten clientseitigen Support und darauf basierend mit "
ttyd" auch eine hübsche Server-Version. Die braucht dann wiederum die "
libwebsockets" ... das kann aber alles keine "rocket science" sein, denn "ttyd" gibt es auch als Paket für LEDE und die Anpassungen für Freetz (bzw. die FRITZ!Box) dürften nicht so gewaltig sein.
Da Shell-in-a-Box vom ursprünglichen Autoren nicht mehr weiterentwickelt wird (und auch die Version in Freetz dem Debian-Fork von Shell-in-a-Box um einiges hinterher hinkt - und z.B. diesen Fix nicht enthält:
https://seclists.org/fulldisclosure/2018/Oct/50), spiele ich mit dem Gedanken, den "ttyd" auch für Freetz aufzubereiten.
Nicht in naher Zukunft, aber Schritt für Schritt in "kreativen Pausen", beginnend mit der "libwebsockets". Da ich - abseits der Recherchen, was am besten wäre - noch nicht so viel Zeit investiert habe, wäre es mir auch egal, wenn das jemand anderes übernimmt ... ich will das nur vorher abstimmen / klären, damit man sich hinterher an dieser Stelle nicht wieder ins Gehege kommen kann.
Solltest Du Dich also selbst mit dem Gedanken tragen, das Shell-in-a-Box-Paket in Freetz zu ersetzen (oder auf den Debian-Stand zu hieven), wäre es nett, wenn Du das "ansagst" ... das fiel mir nur ein, als ich von Dir etwas zu "shellinaboxd" las.
