@tetzlav:
Direkt aus einem MTD würde ich das gar nicht erst versuchen.
Zuerst solltest Du mal klären (df -h), wieviel Platz im tmpfs Du hast.
Reicht der für den Dump der größten Partition (keine Ahnung, was da "sf0" sein soll), kannst Du die mit "cat" (über die char-Devices) oder "dd" über die Block-Geräte in ein Image im tmpfs dumpen ... das macht natürlich für die vier UBIFS(?)-Partitionen nur bedingt Sinn. Was sich dahinter jeweils wirklich verbirgt bei den Dateisystem-Partitionen, mußt Du halt ermitteln ... in /proc/mounts sollte schon mal etwas stehen und irgendwie werde ich den Verdacht nicht los, daß Du bisher auch nur den ARM-Core (das ist doch auch ein Puma6?) erwischt hast. Der andere Kern muß ja auch irgendwo laufen und vermutlich hat der am Ende auch das vor Dir gesuchte GUI ... keine Ahnung, welche IP der hat, aber wenn der mit dem ARM-Core nicht nur über die Mailbox kommuniziert, sollte man ja im "netstat" etwas sehen können oder man macht halt einen Scan. Irgendwo im LAN muß der x86-Core stecken.
Ob am Ende beide Systeme dieselben Partitionen sehen oder nicht bzw. wo sich diese überschneiden, mußt Du erst einmal vorsichtig ermitteln.
Dateisystem-Partitionen solltest Du jedenfalls (besonders wenn die einen UBI-Layer unterhalb des Dateisystems haben) nicht mit "dd" oder "cat" auslesen, das wird nur unnötig kompliziert, wenn man die außerhalb wieder mounten und auslesen will ... hier kann schon ein einfaches "tar" vom Mountpoint an (wenn das nicht gerade das rootFS ist, da macht das komplette "tar" weniger Sinn und man müßte vielleicht mit "find -xdev" vorselektieren) vollkommen ausreichen und das läßt sich dann auch wieder viel einfacher weiterverarbeiten.
Beim Bootloader und beim Kernel (keine Ahnung, wo der zweite Kernel ist, der würde für mein Empfinden erst einmal fehlen) ist dann der Dump ins tmpfs mit anschließender TFTP-Übertragung (es gibt vermutlich auch das "ti_tftp", das ist etwas besser zu handhaben) wohl wirklich die beste Möglichkeit. Reicht der Platz im tmpfs irgendwie nicht aus (es kann auch gut sein, daß das auf dem anderen Kern besser aussieht, deshalb ja vorher suchen), wäre vielleicht eine Pipe mit "nc" (vielleicht ist auf dem x86-Core die BusyBox ja umfangreicher, wenn nicht, ist ein x86-"nc" (statisch gelinkt) ja schnell erstellt, dafür braucht man nicht einmal eine ARM-Toolchain) eine denkbare Alternative, weil dann die Buffer das einzige sind, was benötigt wird und das gleich "live" weggeschrieben wird.
Das mit den Partitionen sieht auch irgendwie erst einmal komisch aus, vielleicht gibt es da noch eine Stage beim Loader mehr und der Kernel aus "Kernel" (i.V.m. dem "Rootfilesystem") lädt tatsächlich eine "vmlinu?.irgendwas" aus den Dateisystem-Partitionen in den Speicher, bevor er denen die Steuerung auf dem jeweiligen Core übergibt - ist aber auch nur geraten, vielleicht verrät "dmesg" ja mehr, wie das abläuft.
Aber eben immer schön der Reihe nach, niemand löscht Dir irgendwelche Daten, Du hast also alle Zeit der Welt.
Ich würde als nächstes jetzt mal nach dem x86-Core suchen (wenn er das nicht sogar ist, das sagt aber ein "cat /proc/cpuinfo" und dann mußt Du eben den ARM-Core suchen) und dort mal nach einer Shell schauen. Anschließend die gemounteten Partitionen ansehen und dann erhält man Stück für Stück eine Vorstellung, was da wie umgesetzt wurde von Hitron.
Zur Provisionierung: Anders als bei Provider-6490 vs. Retail-6490 kann hier der Provider natürlich "sehen", daß es kein "zugelassenes" Gerät ist. Hat das eigentlich nun die "offiziellen Weihen" von CableLabs oder nicht? Das "CW93 planned" war ja nun schon auf dem Flyer aus 2012 zu lesen ... ich habe noch nicht bei CableLabs nachgesehen, wie da der Stand ist (wobei auch Hitron dazu sicherlich etwas schreiben kann).
Es hilft also auch nicht, jetzt ein gültiges AVM-Zertifikat herzunehmen und die CM-MAC des Modems passend zu setzen ... das ist zwar theoretisch sogar denkbar, dann ist das aber immer noch (spätestens beim DHCP und SNMP) als Hitron-Gerät zu erkennen und je nachdem, wie genau der Provider hinschaut, kann man ihm da auch kein X für ein U vormachen.
Die entscheidende Frage hier wäre vielleicht, ob die Anforderungen eine DOCSIS3-Zertifizierung oder nur DOCSIS3-Kompatibilität verlangen (müßte man noch einmal ganz genau nachlesen) ... daß in dem ANGA-Dokument das OSSI-Chapter 9.2 nur "informative" ist, hatte ich schon zwei-/dreimal geschrieben und wie weit man auf das eCM überhaupt einwirken kann über die bereitgestellte Shell, kann man ohne ausführliches "Studium" der Menüs auch nur raten. Die Forderung lautet schließlich, daß man darüber keinen Zugriff auf das CM erhalten darf ... hinter dem CMCI ist das unproblematisch und solange da nur Abfragen/Anzeigen des CM-Zustands möglich sind, ist das ggf. nicht einmal der "console port" aus dem OSSI-Kapitel.
Die kolportierte Aussage des Support-Mitarbeiters würde ich gleich mal dem Beschwerdemanagement "vortragen" (von solchen Leuten notiert man sich ja automatisch den Namen), mit freundlichem CC an die BNetzA ... selbst wenn nicht sofort etwas passiert, macht es irgendwann mal die Masse - das sind noch nicht 10, aber 100 sind dann schon wieder "eine Macht" und wenn davon 10 dann der BNetzA genug auf die Ketten gehen, damit das nicht versandet, dann taucht das irgendwann auch in deren Berichten auf (ist ja eine Behörde, da geht so schnell nichts verloren) und da macht sich ein (unbegründetes) "Wir haben das halt so laufen lassen." dann auch nicht so gut im "Rechenschaftsbericht" (die haben schon genug damit zu tun, die Vorurteile zu den Abläufen und dem Stempelkissen auf der Stirn nach der Mittagsruhe zu entschärfen).
