AW: VU+ Solo 2 Clone - Diskussionsthread #2 (Erfahrungen, Probleme und allgemeine Fra
kannst ja mal den Kernel vom 25.09. runterladen.......ob den die Box verträgt?
Angzeigt wird en obskurer Kernel im Menü den das gepatchte VTI 7.0 hat
Der neue Kernel ist der gleiche wie der alte ... also von der Versionsnummer her.
Da der Kernel sowieso immer von den Image-Teams aus den offiziellen Quellen (plus ggf. ein paar Patches) neu gebaut wird, ist das auch nicht der Angriffsvektor, den Vu+ nutzt.
Würde Vu+ über seine Kernel-Patches angreifen, hätten die Chinesen nur ein klitzekleines Stück Code zu überprüfen um haarklein zu wissen, was Vu+ prüft und was sie danach kaputtmachen.
Dann bräuchte man nur noch
- dieses winzige Codeschnippselchen wegzulassen
oder
- das Gegenstück zu diesem Code in Clone implementieren, so daß die Prüfung erfolgreich verläuft
und hätte wirklich einen 100%-Clone.
Tatsächlich greift Vu+ über die Treiber/Kernel-Module an, die sie nur in binärer Form zur Verfügung stellen.
Die sind zwar indirekt auch Bestandteil des Kernels und hängen von seiner Version ab (Auch wenn's Module und getrennte Dateien sind ist der Kernel im Prinzip immer noch monolithisch), aber solange dieselbe Kernel-Version verwendet wird (und daran nichts im Zusammenhang mit den vom Treiber verwendeten Schnittstellen gepatcht wird), paßt auch das alte Kernel-Modul immer noch.
Ich habe jetzt keine Stunden in den Vergleich gesteckt, aber soweit ich das überblicken kann, haben die chinesischen Treiber/Kernel-Module eigentlich gar nix mit denen von Vu+ zu tun, sondern sind genauso selbst gebastelt wie die auf einer Gigablue oder Edision.
Insofern ist die Sache mit den Clones Augenwischerei, genausogut hätte man einen echten
Edision Optimuss OS2+ in das Gehäuse einer Vu+ Solo² basteln können und an allen Stellen, wo "
Edision Optimuss OS2+" ausgegeben wird "Vu+ Solo²" hinschreiben können.
Oder umgekehrt: Man hätte das Teil auch ohne technische Änderungen und ohne das Gehäuse einer Vu+ Solo² nachzubauen als (Lonrisun|Sunray|Dragonworth) Solo³ auf den Markt schmeißen können und es wäre kein Clone.
Bei einem Kernel-/Treiber-Update passiert nun folgendes:
Der Kernel selber wird durchaus aktualisiert, aber die Treiber durch den Schreibschutz nicht (Solange der neue Kernel dieselbe Version hat wie der alte).
Deshalb sind Kernel-Updates erst einmal problemlos, wobei der tatsächlich genutzte Treiber allerdings tatsächlich der alte bleibt (Egal was irgendwo angezeigt wird, diese Anzeigen werten nur das zuletzt installierte Treiber-ipk aus, ob es zuende installiert wurde oder nicht).
Meine Solo² ist auch der festen Überzeugung, die Treiber vom 25.09.2014 zu nutzen ...
Driver date: 20140925
Kernelversion: 3.13.5
... tut sie aber nicht:
root@solo2:~# ls -la /lib/modules/3.13.5/extra/
-rw-r--r-- 1 root root 5168
Sep 6 15:43 brcmfb.ko
-rw-r--r-- 1 root root 8996508
Sep 6 15:43 dvb-bcm7356.ko
-rw-r--r-- 1 root root 2376
Sep 6 15:43 fpga_directc.ko
-rw-r--r-- 1 root root 4412
Sep 6 15:43 procmk.ko
Problematisch wird es, wenn der neue Kernel auch eine neuere Versionsnummer trägt, denn dann liegen dessen Module in einem neuen Verzeichnis und das Anlegen desselben kann der Schreibschutz auf den alten Modulen nicht verhindern.
Dann werden beim Neustart der neue Kernel und damit auch die neuen Treiber aktiv und es macht *Bumm*.
