Streamboard Wiki - Benutzerbeiträge [de-at]

HowTo - Vom Auschecken bis zum Image

2006-12-10T02:24:53Z

Limette: /* '''"make all" - Jetzt gehts los''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =

Bevor wir "make all" eingeben, sollten wir bedenken, dass evtl. 100 MB an Sourcen gesaugt werden müssen. Wenn wir die Sourcen bereits mal gesaugt hatten, müssen wir das nicht nochmal komplett wiederholen. Es kann sein, dass der aktuelle CDK-Stand einige, wenige NEUE Sourcen (Archive) saugt. Das ist zB. der Fall, wenn ein neuer Kernel im CDK aufgenommen wurde. Dann wird der komplette Kernel-Source gesaugt. Das sind gut 30 MB. Aber auch wenn sich einige Treiber (zB. PNG, oder MP3, oder sonstiges) im CDK erneuert haben, werden Sourcen neu gesaugt.
FALLS man also auf seinem PC die ganzen Archive bereits zuvor runtergeladen hatte, empfiehlt sich nach der "autogen.sh", und der "configure"-Zeile ein Symlink zu einem Verzeichnis, in dem das ganze Zeug bereits liegt. Nehmen wir mal an, unter

$HOME/alter_versuch/tuxbox-cvs/cdk/Archive

wären die ganzen (bereits runtergeladenen) Archive, dann ertsellen wir einen Symlink, damit nur noch die *neuesten* Archive gesaugt werden...

cd $HOME/tuxbox-cvs/cdk
ln -s $HOME/alter_versuch/tuxbox-cvs/cdk/Archive $HOME/tuxbox-cvs/cdk/Archive

Bitte auf Gross/Kleinschreibung achten... Kontrolliert runterladen, können wir die neuen Archive (vor "make all") durch Eingabe von

sb@build/tuxbox-cvs/cdk# make download

Wenn nun ein Archiv nicht runterlädt, und mit einer Fehlermeldung abbricht, bemühen wir zB. Google. Wenn wir das vermisste Archiv gefunden haben, speichern wir es in entweder (weil wir "Neulinge" sind) im frischen Archiv-Verzeichnis, oder in dem ge-symlimkten (alten) Archiv-Verzeichnis.

Wiederholt solange "make download" eingeben, bis die Ausgabe sagt, es gäbe nix mehr zu tun... Nun sind wir ENDLICH bereit für ein:

sb@build/tuxbox-cvs/cdk# make all

Dies dauert je nach PC unter Linux etwa 70-120 Minuten. Wenn man "Neuling" ist, kann man auch durchaus direkt "make all" eingeben (zuvoriges "make download" weglassen. Das "make all" schubst dann auch die Archiv-Downloads an. Sofern man einen dicken DSL-Anschluss hat, und auch alle an-gepingten Sourcen/Archive-Server Online sind, läuft der ganze Prozess im Hintergrund, und man muss überhaupt nichts machen. Das wäre der optimale Fall...

== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T02:17:49Z

Limette: /* '''"make all" - Jetzt gehts los''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =

Bevor wir "make all" eingeben, sollten wir bedenken, dass evtl. 100 MB an Sourcen gesaugt werden müssen. Wenn wir die Sourcen bereits mal gesaugt hatten, müssen wir das nicht nochmal komplett wiederholen. Es kann sein, dass der aktuelle CDK-Stand einige, wenige NEUE Sourcen (Archive) saugt. Das ist zB. der Fall, wenn ein neuer Kernel im CDK aufgenommen wurde. Dann wird der komplette Kernel-Source gesaugt. Das sind gut 30 MB. Aber auch wenn sich einige Treiber (zB. PNG, oder MP3, oder sonstiges) im CDK erneuert haben, werden Sourcen neu gesaugt.
FALLS man also auf seinem PC die ganzen Archive bereits zuvor runtergeladen hatte, empfiehlt sich nach der "autogen.sh", und der "configure"-Zeile ein Symlink zu einem Verzeichnis, in dem das ganze Zeug bereits liegt. Nehmen wir mal an, unter

$HOME/alter_versuch/tuxbox-cvs/cdk/Archive

wären die ganzen (bereits runtergeladenen) Archive, dann ertsellen wir einen Symlink, damit nur noch die *neuesten* Archive gesaugt werden...

cd $HOME/tuxbox-cvs/cdk
ln -s $HOME/alter_versuch/tuxbox-cvs/cdk/Archive $HOME/tuxbox-cvs/cdk/Archive

Bitte auf Gross/Kleinschreibung achten... Kontrolliert runterladen, können wir die neuen Archive (vor "make all") durch Eingabe von

sb@build/tuxbox-cvs/cdk# make download

Wenn nun ein Archiv nicht runterlädt, und mit einer Fehlermeldung abbricht, bemühen wir zB. Google. Wenn wir das vermisste Archiv gefunden haben, speichern wir es in entweder (weil wir "Neulinge" sind) im frischen Archiv-Verzeichnis, oder in dem ge-symlimkten (alten) Archiv-Verzeichnis.

Wiederholt solange "make download" eingeben, bis die Ausgabe sagt, es gäbe nix mehr zu tun... Nun sind wir ENDLICH bereit für ein:

sb@build/tuxbox-cvs/cdk# make all

Dies dauert je nach PC unter Linux etwa 70-120 Minuten. Wenn man "Neuling" ist, kann man auch durchaus direkt "make all" eingeben. Das "make all" schubst auch die Archiv-Downloads an. Sofern man einen dicken DSL-Anschluss hat, und auch alle an-gepingten Sourcen/Archive-Server Online sind, läuft der ganze Prozess im Hintergrund, und man muss überhaupt nichts machen. Das wäre der optimale Fall...

== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T02:15:09Z

Limette: /* '''"make all" - Jetzt gehts los''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =

Bevor wir "make all" eingeben, sollten wir bedenken, dass evtl. 100 MB an Sourcen gesaugt werden müssen. Wenn wir die Sourcen bereits mal gesaugt hatten, müssen wir das nicht nochmal komplett wiederholen. Es kann sein, dass der aktuelle CDK-Stand einige, wenige NEUE Sourcen (Archive) saugt. Das ist zB. der Fall, wenn ein neuer Kernel im CDK aufgenommen wurde. Dann wird der komplette Kernel-Source gesaugt. Das sind gut 30 MB. Aber auch wenn sich einige Treiber (zB. PNG, oder MP3, oder sonstiges) im CDK erneuert haben, werden Sourcen neu gesaugt.
FALLS man also auf seinem PC die ganzen Archive bereits zuvor runtergeladen hatte, empfiehlt sich nach der "autogen.sh", und der "configure"-Zeile ein Symlink zu einem Verzeichnis, in dem das ganze Zeug bereits liegt. Nehmen wir mal an, unter

$HOME/alter_versuch/tuxbox-cvs/cdk/Archive

wären die ganzen (bereits runtergeladenen) Archive, dann ertsellen wir einen Symlink, damit nur noch die *neuesten* Archive gesaugt werden...

cd $HOME/tuxbox-cvs/cdk
ln -s $HOME/alter_versuch/tuxbox-cvs/cdk/Archive $HOME/tuxbox-cvs/cdk/Archive

Bitte auf Gross/Kleinschreibung achten... Kontrolliert runterladen, können wir die neuen Archive (vor "make all") durch Eingabe von

sb@build/tuxbox-cvs/cdk# make download

Wenn nun ein Archiv nicht runterlädt, und mit einer Fehlermeldung abbricht, bemühen wir zB. Google. Wenn wir das vermisste Archiv gefunden haben, speichern wir es in entweder (weil wir "Neulinge" sind) im frischen Archiv-Verzeichnis, oder in dem ge-symlimkten (alten) Archiv-Verzeichnis.

Wiederholt solange "make download" eingeben, bis die Ausgabe sagt, es gäbe nix mehr zu tun... Nun sind wir ENDLICH bereit für ein:

sb@build# make all

Dies dauert je nach PC unter Linux etwa 70-120 Minuten. Wenn man "Neuling" ist, kann man auch durchaus direkt "make all" eingeben. Das "make all" schubst auch die Archiv-Downloads an. Sofern man einen dicken DSL-Anschluss hat, und auch alle an-gepingten Sourcen/Archive-Server Online sind, läuft der ganze Prozess im Hintergrund, und man muss überhaupt nichts machen. Das wäre der optimale Fall...

== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:58:50Z

Limette: /* '''"make all" - Jetzt gehts los''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =

Bevor wir "make all" eingeben, sollten wir überlegen, dass evtl. 100 MB an Sourcen gesaugt werden müssen. Wenn wir die Sourcen bereits mal gesaugt hatten, müssen wir das nicht nochmal komplett wiederholen. Es kann sein, dass der aktuelle CDK-Stand einige, wenige NEUE Sourcen (Archive) saugt. Das ist zB. der Fall, wenn ein neuer Kernel im CDK aufgenommen wurde. Dann wird der komplette Kernel-Source gesaugt. Das sind gut 30 MB. Aber auch wenn sich einige Treiber (zB. PNG, oder MP3, oder sonstiges) im CDK erneuert haben, werden Sourcen neu gesaugt.
FALLS man also auf seinem PC die ganzen Archive bereits runtergeladen hatte, empfiehlt sich nach der "autogen.sh", und der "configure"-Zeile ein Symlink zu einem Verzeichnis, in dem das ganze Zeug bereits grösstenteils liegt. Nehmen wir mal an, unter

$HOME/alter_versuch/tuxbox-cvs/cdk/Archive

wären die ganzen (bereits runtergeladenen) Archive, dann geben wir einen Symlink ein, damit nur noch die neuesten Archive gesaugt werden müssen...

cd $HOME/tuxbox-cvs/cdk
ln -s $HOME/alter_versuch/tuxbox-cvs/cdk/Archive $HOME/tuxbox-cvs/cdk/Archive

Kontrolliert runterladen, können wir die neuen Archive (vor "make all") durch Eingabe von

sb@build/tuxbox-cvs/cdk# make download

Wenn nun ein Archiv nicht runterlädt, und mit einer Fehlermeldung abbricht, bemühen wir zB. Google. Wenn wir das vermisste Archiv gefunden haben, speichern wir es in entweder (weil wir "Neulinge" sind) im frischen Archiv-Verzeichnis, oder in dem ge-symlimkten (alten) Archiv-Verzeichnis.

Wiederholt solange "make download" eingeben, bis die Ausgabe sagt, es gäbe nix mehr zu tun... Nun sind wir ENDLICH soweit für ein:

sb@build# make all

Dies dauert je nach PC unter Linux etwa 70-120 Minuten.

== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:48:11Z

Limette: /* '''"make all" - Jetzt gehts los''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =

Bevor wir "make all" eingeben, sollten wir überlegen, dass evtl. 100 MB an Sourcen gesaugt werden müssen. Wenn wir die Sourcen bereits mal gesaugt hatten, müssen wir das nicht nochmal komplett wiederholen. Es kann sein, dass der aktuelle CDK-Stand einige, wenige NEUE Sourcen (Archive) saugt. Das ist zB. der Fall, wenn ein neuer Kernel im CDK aufgenommen wurde. Dann wird der komplette Kernel-Source gesaugt. Das sind gut 30 MB. Aber auch wenn sich einige Treiber (zB. PNG, oder MP3, oder sonstiges) im CDK erneuert haben, werden Sourcen neu gesaugt.
FALLS man also auf seinem PC die ganzen Archive bereits runtergeladen hatte, empfiehlt sich nach der "autogen.sh", und der "configure"-Zeile ein Symlink zu einem Verzeichnis, in dem das ganze Zeug bereits grösstenteils liegt. Nehmen wir mal an, unter

$HOME/test/tuxbox-cvs/Archive

wären die ganzen (bereits runtergeladenen) Archive, dann geben wir einen Symlink ein, damit nur noch die neuesten Archive gesaugt werden müssen...

cd $HOME/tuxbox-cvs/cdk
ln -s $HOME/test/cdk/tuxbox-cvs/Archive $HOME/tuxbox-cvs/cdk/Archive

Kontrolliert runterladen, können wir die neuen Archive (vor "make all") durch Eingabe von

sb@build# make download

Wenn nun ein Archiv nicht runterlädt, und mit einer Fehlermeldung abbricht, bemühen wir zB. Google. Wenn wir das vermisste Archiv gefunden haben, speichern wir es in dem entsprechenden Archiv-Verzeichnis (das kann durchaus auch das alte sein, da wir ja nun einen Symlink zu dem alten Archiv-Verzeichnis im Neuen "tuxbox-cvs/cdk/Archive" gesetzt haben; wenn wir "Neulinge" sind, wird der ganze Kram halt in dem Verzeichnis $HOME/tuxbox-cvs/cdk/Archive gedownloadet)

Wiederholt solange "make download" eingeben, bis die Ausgabe sagt, es gäbe nix mehr zu tun... Nun sind wir ENDLICH soweit für ein:

sb@build# make all

Dies dauert je nach PC unter Linux etwa 70-120 Minuten.

== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:22:43Z

Limette: /* Konfigurieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

Wenn man das "--disable-libcrypto" weglässt, erstellt das CDK eine dicke, 700kB grosse Libcrypto-Lib. Das ist für ein kleinen FlashROM-Speicher 'ne Menge Holz, zumal es evtl. gar nicht gebraucht wird. Deswegen machen wir es anders: Wir "disablen" es hier, und erstellen es nachträglich. Wenn wir später (zb. die Evocamd) ins Image einbinden wollen, und dazu die Libs anpassen, wird nur ein geringer Teil der libcrypto (nur das, was benötigt wird) erstellt. Mehr dazu hier im Wiki.

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:16:52Z

Limette: /* Konfigurieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash --disable-libcrypto

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:14:50Z

Limette: /* mklibs kopieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Es kann sein, dass man sich (um dies kopieren zu können) dafür kurzfristig als root einloggen muss, oder als Superuser.
Diese mklibs.py ist für die libcrypto zuständig.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:12:20Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:10:33Z

Limette: /* '''Vorbereitungen zum Compilieren''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T01:00:44Z

Limette: /* Konfigurieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T00:58:33Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root, auch wenn sein $HOME nicht unter /home zu finden ist). Gäbe es den User "Linuxfreak", und der PC würde unter Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, befände man sich nach dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Vor dem Eingabecursor stünde nun folgendes vorab:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des jeweiligen PC-Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T00:54:36Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root). Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Die Eingabezeile des Cursors hätte nun folgendes vorab stehen:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-10T00:03:47Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root). Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Wenn man es so, wie hier beschrieben eintippt, geht man sicher, dass die beiden Verzeichnisse auch an der richtigen Stelle angelegt werden. Denn es könnte ja sein, dass man sich bei der Eingabe der beiden Befehle total verwurzelt in einem Sub-Sub-Sub-Verzeichnis befindet. Deswegen das $HOME davor.
Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie hier vorgeschlagen.

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-09T23:58:43Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME kennt idR. jede Linux-Distribution von Haus aus. Sie zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root). Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie es hier beschrieben wird. Warum auch nicht!?

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-09T23:57:47Z

Limette: /* Zwei wichtige Arbeits-Verzeichnisse anlegen */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==

Die Variable $HOME zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users. Jeder User hat ein eigenes Heimverzeichnis (sogar der root). Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

Es empfiehlt sich die zwei wichtigen Verzeichnisse im /home-Verzeichnis des Users anzulegen:

sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Die beiden Verzeichnisse können auch anders heissen, man muss sich aber JETZT für einen Namen entscheiden! Da aber folgende Texte in diesem HowTo sich stets auf diese Verzeichnisse beziehen (und auch wenig gegen einen anderen Namen spricht), wäre es empfehlenswert, es so zu machen, wie es hier beschrieben wird. Warum auch nicht!?

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-09T23:50:41Z

Limette: /* '''Vorbereitungen zum Compilieren''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen. Hier im Wiki heisst unser User "sb", und der PC auf dem das Linux läuft, wurde im Linux "build" getauft.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==
sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Die Variable $HOME zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users (hier der User "sb"). Jeder User hat ein eigenes Heimverzeichnis. Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-09T23:47:30Z

Limette: /* Ein paar Verzeichnisse anlegen (tuxbox-cvs, dbox2, etc) */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Zwei wichtige Arbeits-Verzeichnisse anlegen==
sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Die Variable $HOME zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users (hier der User "sb"). Jeder User hat ein eigenes Heimverzeichnis. Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-12-09T23:46:50Z

Limette: /* Ein paar Verzeichnisse anlegen (tuxbox-cvs, dbox2, etc) */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD] muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:
* fakeroot
* mksquashfs >= 2.1
* mkcramfs
* mkfs.jffs2

Es gibt im Tuxbox-CVS den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh
Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

=== Debian ===
Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.
==== apt-setup ====
''apt-setup'' dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert.
Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

=== SuSE ===

Unter SuSE koennt ihr mit ''rpm -q <paketname>'' anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit dem Befehl
root@build:~# rpm -i <paketname>
könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
root@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in Englisch)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch Englisch)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2
* mkcramfs

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMware Beta-Buildumgebung===
Um die Erstellung eines Images für Nicht-Linuxuser zu vereinfachen steht ein fertiges VMware-Image bereit, das bereits alle nötigen Voraussetzungen enthält. Näheres hierzu findet sich in diesem seperaten Artikel: [[Streamboard_Buildumgebung|Streamboard Buildumgebung]]

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

==Ein paar Verzeichnisse anlegen (tuxbox-cvs, dbox2, etc)==
sb@build:# mkdir $HOME/tuxbox-cvs
sb@build:# mkdir $HOME/dbox2

Die Variable $HOME zeigt auf das /home-Verzeichnis des derzeit angemeldeten Users (hier der User "sb"). Jeder User hat ein eigenes Heimverzeichnis. Gäbe es den User "Linuxfreak", und der PC würde im Linux "MeinPC" heissen, und man wäre als "Linuxfreak" angemeldet, wäre man bei dem Befehl....

cd $HOME

... im Heimverzeichnis des Users "Linuxfreak". Der Cursor würde nun so aussehen:

Linuxfreak@MeinPC:#

==Auschecken==
Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 up -dP .

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

==mklibs kopieren==
Die Datei mklibs muss noch entsprechend nach ''/usr/bin'' kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:
sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

==Konfigurieren==
Im Anschluss daran fehlt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Ein Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [http://www.beyondlogic.org/nb5/squashfs_lzma.htm] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
* SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den ''Default-Einstellungen'' im CVS zufrieden ist)!

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==
Die Datei camd.c im Verzeichnis ~/tuxbox-cvs/apps/tuxbox/tools/camd/ gehört geringfügig angepaßt.
Genaugenommen muß nur eine Abfrage auskommentiert werden.
Nachfolgende Sequenz in eine Datei camd.c.diff kopieren

--- camd.c 2004-04-04 22:27:57.000000000 +0200
+++ camd_withP.c 2006-11-26 09:30:29.000000000 +0100
@@ -415,14 +415,14 @@
pmt->ca_pmt_list_management = buffer[0];
pmt->program_number = *(unsigned short *)&buffer[1];
pmt->program_info_length = *(unsigned short *)&buffer[4] & 0x0fff;
-
+/*
if ((pmt->program_number & 0xf000) == 0x0000) {
printf("[camd] program number %04x unsupported due to missing parental control\n",
pmt->program_number);
free(pmt);
return -1;
}
-
+*/
#if 0
printf("ca_pmt_list_management: %02x\n", pmt->ca_pmt_list_management);
printf("program number: %04x\n", pmt->program_number);

und mit
patch -p0 -b camd.c camd.c.diff
übernehmen

siehe auch [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_diff_.3F]]
und [[HowTo_-_Vom_Auschecken_bis_zum_Image#Was_ist_ein_Patch_.3F]]

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==

Nun muss eine passender u-boot gebaut werden. Dazu muss die

- u-boot.squashfs.dbox2.h
in$HOME/tuxbox-cvs/boot/u-boot-config und link von der Datei auf u-boot.config
$HOME/tuxbox-cvs/boot/u-boot-config> ln -s u-boot.squashfs.dbox2.h u-boot.config
Editiert werden.
anschliessend
in /tucbox-cvs/cdk/

rm .deps/u-boot
make u-boot

Dieser u-boot liegt dann in

/dbox2/tftpboot
und muss nach

/$HOME/tuxbox-cvs/hostapps/mkflfs/
kopiert werden.

Dort erzeugt man dann zunächst mkflfs mit den folgenden befehlen

gcc -o mkflfs mkflfs.c minilzo.c
dann je nach gewünschten flashbausteinanzahl

./mkflfs 2x u-boot

nun haben wir eine datei namens flfs.img und benennen diese entsprechend nach flfs1x.img oder flfs2x.img um. Kopieren diese Datei nach $HOME/dbox2/cdkflash

== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T16:34:26Z

Limette: /* Wo liegen die Vor- und Nachteile der Filesysteme? */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von hier [[Bild:VMwareTools.exe]] das Archiv und extrahiert daraus die TAR-Datei. Mit einem FTP Client könnt ihr diese dann mittels des in der Buildumgebung integrierten FTP-Servers hineinkopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch vorher noch die passenden Kernelheaders zu dem aktuellen Kernel.

==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball erstellen)

Hier fehlt jetzt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
* SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
* SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
* CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
* JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T15:19:34Z

Limette: /* '''Vorbereitungen zum Compilieren''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von der VMWare Seite den [http://download3.vmware.com/software/vmserver/VMware-server-1.0.1-29996.tar.gz Server für Linux]
Aus diesem extrahiert ihr euch das Iso-File "linux.iso", dieses dann mit zB mit Deamon Manager öffnen und das File VMWARETO.TGZ lokal am PC abspeichern. Mit einem FTP Client könnt ihr es dann in die Buildumgebung kopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch voher noch die passenden Kernelheaders zu dem aktuellen Kernel.
==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball erstellen)

Hier fehlt jetzt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
# SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
# SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
# CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
# JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T15:17:58Z

Limette: /* '''Vorbereitungen zum Compilieren''' */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von der VMWare Seite den [http://download3.vmware.com/software/vmserver/VMware-server-1.0.1-29996.tar.gz Server für Linux]
Aus diesem extrahiert ihr euch das Iso-File "linux.iso", dieses dann mit zB mit Deamon Manager öffnen und das File VMWARETO.TGZ lokal am PC abspeichern. Mit einem FTP Client könnt ihr es dann in die Buildumgebung kopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch voher noch die passenden Kernelheaders zu dem aktuellen Kernel.
==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =

Falls nicht schon geschehen, jetzt als User einloggen.
Anmerkung: Dieser Username erscheint auch später in Eurem Image

== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball erstellen)

Hier fehlt jetzt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
# SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
# SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
# CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
# JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T15:14:25Z

Limette: /* Auschecken und Konfigurieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von der VMWare Seite den [http://download3.vmware.com/software/vmserver/VMware-server-1.0.1-29996.tar.gz Server für Linux]
Aus diesem extrahiert ihr euch das Iso-File "linux.iso", dieses dann mit zB mit Deamon Manager öffnen und das File VMWARETO.TGZ lokal am PC abspeichern. Mit einem FTP Client könnt ihr es dann in die Buildumgebung kopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch voher noch die passenden Kernelheaders zu dem aktuellen Kernel.
==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =
Wichtig ist für euer System, dass ihr '''nicht''' unter dem User root arbeitet, zumindestens nicht das CDK kompiliert. Richtet euch eine eigenen User ein (der Username taucht dann auch im Image auf), mit dem ihr dann arbeitet. Einige Teile müßt ihr natürlich immer unter dem User root machen, zB Verzeichnisse anlegen oder Programme installieren. In diesem Howto wird immer von den selben Verzeichnissen gesprochen. In den weiteren Beispielen gehen wir davon aus, dass der User '''''tux''''' heist und unser Rechner '''''linuxrechner'''''. Natürlich könnt ihr auch eure eigenen Namen vergeben ;-)
== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball erstellen)

Hier fehlt jetzt noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
# SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
# SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
# CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
# JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T15:13:24Z

Limette: /* Auschecken und Konfigurieren */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von der VMWare Seite den [http://download3.vmware.com/software/vmserver/VMware-server-1.0.1-29996.tar.gz Server für Linux]
Aus diesem extrahiert ihr euch das Iso-File "linux.iso", dieses dann mit zB mit Deamon Manager öffnen und das File VMWARETO.TGZ lokal am PC abspeichern. Mit einem FTP Client könnt ihr es dann in die Buildumgebung kopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch voher noch die passenden Kernelheaders zu dem aktuellen Kernel.
==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =
Wichtig ist für euer System, dass ihr '''nicht''' unter dem User root arbeitet, zumindestens nicht das CDK kompiliert. Richtet euch eine eigenen User ein (der Username taucht dann auch im Image auf), mit dem ihr dann arbeitet. Einige Teile müßt ihr natürlich immer unter dem User root machen, zB Verzeichnisse anlegen oder Programme installieren. In diesem Howto wird immer von den selben Verzeichnissen gesprochen. In den weiteren Beispielen gehen wir davon aus, dass der User '''''tux''''' heist und unser Rechner '''''linuxrechner'''''. Natürlich könnt ihr auch eure eigenen Namen vergeben ;-)
== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball)
Doch zunächst noch:
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
# SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
# SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
# CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
# JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

HowTo - Vom Auschecken bis zum Image

2006-10-25T15:10:44Z

Limette: /* Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) */

= '''Vorwort''' =

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "[http://tuxbox.org Tuxbox]" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf.
Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt.
In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

= '''Allgemeines zu Tuxbox [http://de.wikipedia.org/wiki/Cvs CVS]''' =

== Was ist eigentlich CVS? ==

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten ''Head'' bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der ''Head'' ist bei der DBox2 vorzuziehen. Aber neben dem ''Head'' gibts auch noch Verzweigungen, namens ''Branch''. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

== Was ist eigentlich CDK? ==

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

= '''Vorbereitungen auf dem PC''' =
Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.
==root oder user ?==

Antwort: '''User!''' Und zwar immer!

'''Ausnahme''': Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten
# Beim Einloggen in das Betriebssystem als root anmelden
# Als User die root-shell öffnen
# Normale shell öffnen und ''sudo su'', ''sudo'' oder ''su -'' (das "-" ist für die Umgebungsvariablen von "root") eingeben.
# Root und User gleichzeitig und parallel sein.......
:...... da es unter Linux mehrere ''virtuelle Konsolen'', bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.
Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]
zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination
STRG+ALT+[F-Taste]
kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus.
Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen '''gleichzeitig''' starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig.
(In der [[HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung]] wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

== Tools (Prerequisiten) ==

Prerequisiten? Was'n das?
Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:
* cvs
* autoconf >= 2.57a
* automake >= 1.8
* libtool >= 1.4.2
* gettext >= 0.12.1
* make >= 3.79
* makeinfo (texinfo)
* tar
* bunzip2 (bzip2)
* gunzip (gzip)
* patch
* infocmp (ncurses-bin / ncurses-devel)
* gcc 2.95 or >= 3.0
* g++ 2.95 or >= 3.0
* flex
* bison
* pkg-config
* wget
*libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/hostapps/toolchecker/?only_with_tag=MAIN toolchecker] (bashskript), welcher genau diese Versionsstände ermittelt.
Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ''ausführbar'' (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es.
Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC
sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh

=== Debian ===
Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.
==== apt-setup ====
Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.
==== apt-update ====
Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein
root@build:~# apt-get update
wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

==== apt-upgrade ====
!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

=== SuSE ===

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

==== Yast ====
Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

==== rpm ====
Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

=== Andere Linux-Distributionen ===
==== Knoppix ====
KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden.
(Quelle: Knoppix-Homepage)
Download auf der [http://knopper.net/knoppix/ Knoppix-Homepage]
===== Wie bekomme ich Knoppix auf meine Festplatte? =====
* Knoppix von CD/DVD starten
* Shell öffnen
sb@build:# sudo knoppix-installer
oder
sb@build:# knoppix-installer
eingeben und mit '''[Enter]''' bestätigen
* den Anweisungen folgen
Hier mal ein ''Hd Install HowTo'' aus dem [http://www.knoppix.net/wiki/Hd_Install_HowTo Knoppix-Wiki] (leider nur in english)
Hier noch ein [http://www.irongeek.com/i.php?page=videos/knoppix1 Video] zur HD-Istallation (auch english)
===== Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können? =====
Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:
* bison
* libpng2 or libpng3 (DirectFB)
* libtool >= 1.4.2
* makeinfo (texinfo)
* pkg-config
* flex
eventuell noch:
* mksquashfs
* mkfs.jffs2

=== Cygwin unter Windows ===

==== Platzhalter ====

===Streamboard VMWare Beta-Buildumgebung===

Es steht testweise eine Buildumgebung für VMWare bereit.
[http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMWare.exe (70MB)]
Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

# Download und Installation des [http://www.vmware.com/de/download/player/ VMWare-Players] (Freeware) oder [http://www.vmware.com/de/download/ws/ VMWare Workstation] (benötigt nach 30 Tagen eine Lizenz)
# Entpacken der StreamboardVMWare.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
# Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
# Nach dem Start von Debian kann man sich mittels dem Usernamen "streamboard" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard".

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

Das Streamboard-Team würde sich über Rückmeldungen im Forum diesbezüglich sehr freuen!
Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

==== user/Shell ändern ====
Wir haben uns hier dazu geeinigt, den user und Rechnernamen zu vereinfachen. Um jetzt nicht gleich die ganze Buildungebung neu upzuloaden, kann das ja jeder selber machen. Als erstes legt euch mit dem Befehl ''adduser sb'' einen User '''sb''' an. Danach editiert noch die Datei ''/etc/hostname'', ändert dort den Namen in build. Nach dem nächsten reboot habt ihr dann die richtige Umgebung.

==== VMWare Tools installieren ====
Um zB die Größe der Konsole zu verändern, sllte man sich in die Streamboard Build Umgebung die VMWare Tools installieren. Dazu ladet ihr euch am Besten von der VMWare Seite den [http://download3.vmware.com/software/vmserver/VMware-server-1.0.1-29996.tar.gz Server für Linux]
Aus diesem extrahiert ihr euch das Iso-File "linux.iso", dieses dann mit zB mit Deamon Manager öffnen und das File VMWARETO.TGZ lokal am PC abspeichern. Mit einem FTP Client könnt ihr es dann in die Buildumgebung kopieren. Danach das File "enttarren" und in dem Unterverzeichnis vmware-tools-distrib das Perlskript vmware-install.pl starten. In der Installation könnt ihr alle Fragen mit [ENTER] beantworten. Bitte installiert euch voher noch die passenden Kernelheaders zu dem aktuellen Kernel.
==== Mausunterstützung in der Konsole ====
Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.
sb@build:# apt-get install gpm
Bei den meisten Sytemen schaut die Konfigdatei so aus.
# /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=''
sample_rate=
Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

= '''Welche Dateien müssen noch in mein Linux-PC kopiert/installiert werden?''' =

== mklibs in welchen Pfad ? Und Kopie als mklibs.py in selben Pfad! ==
== mkfs.jffs2 kopieren ==
== mksquashfs kopieren ==
== mkcramfs kopieren (Abfrage, ob bereits vorhanden) ==
== mksquashfs (LZMA) ==
== fakeroot ==

= '''Vorbereitungen zum Compilieren''' =
Wichtig ist für euer System, dass ihr '''nicht''' unter dem User root arbeitet, zumindestens nicht das CDK kompiliert. Richtet euch eine eigenen User ein (der Username taucht dann auch im Image auf), mit dem ihr dann arbeitet. Einige Teile müßt ihr natürlich immer unter dem User root machen, zB Verzeichnisse anlegen oder Programme installieren. In diesem Howto wird immer von den selben Verzeichnissen gesprochen. In den weiteren Beispielen gehen wir davon aus, dass der User '''''tux''''' heist und unser Rechner '''''linuxrechner'''''. Natürlich könnt ihr auch eure eigenen Namen vergeben ;-)
== Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc) ==

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

==Auschecken und Konfigurieren==
solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:
sb@build:# export http_proxy="eure_proxy_ip_:_port"
Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:
sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
hier währe die günstige Gelegenheit ein "Backup" von CVS zu machen, siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_erstellen]]
sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

==Tarball erstellen==
Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.
sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2
Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann.
Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. ''tuxbox-cvs_backup_200600912.tar''

==Tarball wiederherstellen==
Damit werden die bestehenden Dateien wieder überschrieben.
sb@build:# cd /
oder
sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

= '''Letzte Chance noch manuell ins Geschehen einzugreifen''' =

== '''Vor-Überlegung: Welche(s) FileSystem(e) nehmen?''' ==

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

== Wo liegen die Vor- und Nachteile der Filesysteme? ==

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.
# SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
# SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
# CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
# JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine ''Realtime-Compress-Engine'' besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit ''Default-Einstellungen'' im CVS zufrieden.

== Jetzt wird gepatcht ==

=== Kernel + U-Boot: JFFS2-Only ===
=== Kernel + U-Boot: SquashFS ===
=== Kernel + U-Boot: SquashFS-LZMA ===
=== Kernel + U-Boot: CramFS ===
=== Busybox ===

== camd2 für Premiereempfang patchen ==

= '''"make all" - Jetzt gehts los''' =
== Was ist ein YADD, und was gibt man hier ein? ==
== Was gibt man für ein Flash-Image ein? ==

= '''Welche GUI nehmen (neutrino/enigma)?''' =
== make neutrino, make neutrino-all, make neutrino-flash-all, make enigma, make enigma-all, make enigma-flash-all, etc... Was denn jetzt? ==
== Ok, fertig... was nun ? ==
=== Neutrino: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Enigma: Folgende Sachen noch Patchen, Kopieren in /cdkflash, Ucodes, folgende Verzeichnisse noch anlegen, blaaa ===
=== Sonstiges: Lcars, make extra, plugins, blubb ===
== rcS, fstab, Ethernet-Files- und Configs ==

= '''Auf der Fehlersuche''' =
== Erste Hilfe... ==
== Der Trick mit dem "touch xyz" ==

== Alles nochmal überprüfen (prerequisiten, Rechte?, mklibs?, usw) ===
== make distclean <-- (oder wie heisst das nochmal?) ==
== Neu compilieren, ohne nochmal den Crosscompiler & Co neu erstellen lassen zu müssen ==
== Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten ==
(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe [[HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen]]

= '''Image erstellen / Yadd erstellen''' =
== uboot/ppcboot und FLFS! Was ist das? Wohin damit? Woher nehmen? ==
== Image erstellen mkfs.jffs2 -be blaaa.. oder mksquashfs blaaa ==
== Yadd erstellen (was muss wohin, welches Programm nehmen, etc.) ==
== Nebs neutrino auch ein enigma Image erstellen lassen (ohne nochmal alles neu starten lassen zu müssen) ==

= '''Flashen!''' =
== Die Expertentools ==
== Der DBox2-Bootmanager ==
== Flashen ohne Bootmanager ==
== Flashen vom Linux aus ==

= '''Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren''' =

Einfach im Source rumtippen. Anschliessen zurück zu ''/tuxbox-cvs/cdk'' wechseln, und zB. ''make neutrino'' eingeben.
Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch ''make all'' eintippen. Ein ''make all'' ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch ''make all'' angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

'''Doch was ist da los? Es tut sich nichts.''' Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

== Was ist ein .dep-File? ==

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

'''HEAD:'''

Im obigen Beispiel liegt das .dep-File von Neutrino unter ''/home/tuxbox-verzeichnis/cdk/.deps/''
Entweder man wechselt in das Verzeichnis hinein, tippt ''rm neutrino'' ein, wechselt wieder mit ''cd ..'' zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich ''rm -f .deps/neutrino'' ein, gefolgt von der make Anweisung.

'''Dreambox-Branch:'''

Wenn man für die Dreambox ausgecheckt hat, findet man das ''.deps'' Verzeichnis nicht. Die .deps liegen direkt im ''/home/tuxbox-verzeichnis/cdk/'' Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung ''rm -f .neutrino'' einzugeben.

== Was ist ein ''diff'' ? ==

Zunächst einmal zur Abkürzung: ''diff'' steht für ''difference'', also Unterschied. Ein diff-File ist also eine Unterschieds-Datei.
Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der ''enigma_main.cpp'' editiert, tippt zuvor noch ein:
sb@build:# cp enigma_main.cpp enigma_main_orig.cpp
Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:
sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff
Fertig ist das diff-File.

== Was ist ein Patch ?==

Genau das Gegenteil vom ''diffen''. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei ''enigma_main.cpp'' ist noch im Originalzustand. Nun kopiert man das ''enigma_main.cpp.diff'' in dasselbe Verzeichnis, und tippt ein:
sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff
Der Parameter ''-b'' gibt an, dass noch ein Backup erstellt werden soll.

== Datums/Uhrzeit-Problematik von Sourcen ==
Zum Zweck, falls man eine Source versehentlich ''kaputtrepariert'' hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal.
Dann stellen wir fest, dass der ''kaputtreparierte'' Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach
touch enigma_main.cpp
und die Datei hat ein neues Datum bekommen.

== Makefiles.. Wat ist dat und wie sind die aufgebaut? Was muss man beachten? ==

= '''Links''' =

Tuxbox-Plattform: http://tuxbox.org/ 
CVS-Server: http://cvs.tuxbox.org/ 
Mailing-List: http://cvs.tuxbox.org/lists/ 
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite 

= '''Credits''' =
Admin 
horsti666 
limette 
martie 
Nessus 
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau

Camd3

2006-10-24T23:36:30Z

Limette: Camd3 wurde nach HowTo - Anleitung Camd3 verschoben

#REDIRECT [[HowTo - Anleitung Camd3]]

HowTo - Anleitung Camd3

2006-10-24T23:36:30Z

Limette: Camd3 wurde nach HowTo - Anleitung Camd3 verschoben

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
''Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !''

'''Linux-"mc":'''
''Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)''

'''Telnet/Putty:'''
''Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"''

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
''Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !''

'''Linux:'''
''Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !''

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

1. Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !

2. Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)

3. Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)

4. Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.

5. Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...

6. Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !

7. Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)

8. Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !

9. Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !

10. Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T23:06:17Z

Limette: /* Top 10 der Fehler, die gemacht werden... */

HowTo - Anleitung Camd3

2006-10-24T23:02:04Z

Limette: /* Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
''Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !''

'''Linux-"mc":'''
''Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)''

'''Telnet/Putty:'''
''Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"''

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
''Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !''

'''Linux:'''
''Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !''

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T23:01:36Z

Limette: /* Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
''Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !''

'''Linux-"mc":'''
''Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)''

'''Telnet/Putty:'''
''Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"''

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
''Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !''

'''Linux:'''
''Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !''

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T23:00:01Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
''Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !''

'''Linux-"mc":'''
''Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)''

'''Telnet/Putty:'''
''Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"''

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
''camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!''

'''Linux/Windows via Putty/Telnet:'''
''Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !''

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
''Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !''

'''Linux:'''
''Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !''

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:58:21Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !

'''Linux-"mc":'''
Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)

'''Telnet/Putty:'''
Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!

'''Linux/Windows via Putty/Telnet:'''
Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !

'''Linux:'''
Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:57:05Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !

'''Linux-"mc":'''
Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)

'''Telnet/Putty:'''
Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!

'''Linux/Windows via Putty/Telnet:'''
Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !

'''Linux:'''
Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:55:11Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:'''
Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !

'''Linux-"mc":'''
Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)

'''Telnet/Putty:'''
Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:'''
camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!

'''Linux/Windows via Putty/Telnet:'''
Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:'''
Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:'''
Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:53:41Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !

'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)

'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:50:35Z

Limette: /* '''Konfiguration der camd3''' */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !
'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)
'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:
'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

== Konfigdateien/Localhost/etc. ==

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
=== camd3.config ===

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

=== Was bedeutet Boxtyp ? ===

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

=== Für was ist der UDP / TCP Port ? ===

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

=== Für was ist der Logeintrag ? ===

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

=== Was bedeutet LOG_HOST ? ===

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

=== Was bedeutete LOG_PORT ? ===

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

=== Was bedeutet LOG_FILE ? ===

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

=== Bedeutung der Log-Ausgaben: ===

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

=== Was bedeuten die Pfad angaben? ===

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

=== Was bedeutet DNS cache in Sekunden? ===

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

=== Was ist der Multichannel mode ? ===

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

=== Welcher slot steht für was? ===

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

=== Warum liest die camd3 meine Original Karte nicht? ===

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

=== Was ist das Kommando D0,D2 bzw. D3? ===

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

=== Wie blocke ich um z.B. mein Abo zu verlängern? ===

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

=== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?===

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

=== camd3.keys ===

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

=== camd3.servers ===
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

=== camd3.users ===
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

=== Services Datei ===

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:43:42Z

Limette: /* Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !
'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)
'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:
'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

# Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
# Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
# Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
# Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
# Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

'''Anmerkung:''' Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''

'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!

'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
== camd3.config ==

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

== Was bedeutet Boxtyp ? ==

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

== Für was ist der UDP / TCP Port ? ==

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

== Für was ist der Logeintrag ? ==

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

== Was bedeutet LOG_HOST ? ==

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

== Was bedeutete LOG_PORT ? ==

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

== Was bedeutet LOG_FILE ? ==

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

== Bedeutung der Log-Ausgaben: ==

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

== Was bedeuten die Pfad angaben? ==

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

== Was bedeutet DNS cache in Sekunden? ==

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

== Was ist der Multichannel mode ? ==

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

== Welcher slot steht für was? ==

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

== Warum liest die camd3 meine Original Karte nicht? ==

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

== Was ist das Kommando D0,D2 bzw. D3? ==

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

== Wie blocke ich um z.B. mein Abo zu verlängern? ==

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?==

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

== camd3.keys ==

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

== camd3.servers ==
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

== camd3.users ==
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

== Services Datei ==

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:38:04Z

Limette: /* Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !
'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)
'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:
'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

- Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
- Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
- Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
- Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
- Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

Anmerkung: Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''
'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
== camd3.config ==

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

== Was bedeutet Boxtyp ? ==

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

== Für was ist der UDP / TCP Port ? ==

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

== Für was ist der Logeintrag ? ==

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

== Was bedeutet LOG_HOST ? ==

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

== Was bedeutete LOG_PORT ? ==

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

== Was bedeutet LOG_FILE ? ==

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

== Bedeutung der Log-Ausgaben: ==

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

== Was bedeuten die Pfad angaben? ==

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

== Was bedeutet DNS cache in Sekunden? ==

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

== Was ist der Multichannel mode ? ==

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

== Welcher slot steht für was? ==

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

== Warum liest die camd3 meine Original Karte nicht? ==

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

== Was ist das Kommando D0,D2 bzw. D3? ==

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

== Wie blocke ich um z.B. mein Abo zu verlängern? ==

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?==

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

== camd3.keys ==

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

== camd3.servers ==
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

== camd3.users ==
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

== Services Datei ==

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:37:37Z

Limette: /* '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !
'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)
'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:
'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

- Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
- Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
- Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
- Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
- Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

Anmerkung: Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''
'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image =

Wichtig!! Denkt immer daran, vorher eine Sicherung eures kompl. Images zu machen, falls mal was daneben geht !!

== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==

Das Programm hat zwar einen Fehler, aber wenn man weiss wie man damit umgehen muss, funzt es einwandfrei !

'''Auslesen des Cramfs-Bereiches'''

Unter der DBox selbst: Cramfs auslesen per Service/Software Aktualisierung/Experten Funktion, via FTP aus /tmp der Box auf den PC holen...

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden...

cat /proc/mtd

dannach erhält man eine Auflistung die so ähnlich aussehen könnte !!

mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 006e0000 00020000 "root (cramfs)"
mtd3: 000e0000 00020000 "var (jffs2)"
mtd4: 007e0000 00020000 "flash without bootloader"
mtd5: 00800000 00020000 "complete flash"

nun wechseln wir nach /tmp mit

cd /tmp

Ist das Cramfs nun zb. ein mtd2 wie im beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > mtd2.img

Nun liegt das Cramfs mit namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Dann das Cramfs mit New-Tux-Flash-Tools öffnen, und mal Platz machen... Z.B. alle Spiele raus; danach kann man ohne Prob. den ganzen Ordner \share\tuxbox\sokoban löschen unter \share\fonts md_khmurabi_10.ttf löschen die braucht niemand. Ausserdem kann man z.B. die Sprachunterstüzungen bis auf Deutsch rausnehmen. Liegt in \share\tuxbox\neutrino\locale ! Und wenn man eine SAT-DBox2 besitzt, könnte man auch noch in \share\tuxbox die cables.xml löschen.

Nun ist Gelegenheit, weitere Dinge in das Image reinzukopieren... (RECHTE NICHT VERGESSEN)
Z.B. camd36xx umbenennen in camd2 und ab nach /bin ! Rechte nicht vergessen... Plugins einfügen nach /lib/tuxbox/plugins einfügen, wenn´s jemand unbedingt dort haben möchte !!

Jetzt geht man auf Extras/Einstellungen, gibt die IP-Adresse, Com-Port und Passwort der DBox ein, und schließt mit ok ab.

Als nächsten Schritt geht man mit einem Rechtsklick auf der linken Seite auf den Cramfs-Heimordner, und klickt auf "Filesystem zur box uploaden" !!!

Nun befindet sich das soeben geänderte Cramfs in /var/tmp Eurer DBox (als cramfs.img), und kann wieder bequem per
Expertenfunktion in die Box geflasht werden !!!
(Service/Software Aktualisierung/Experten Funktion/Einzelne Partition einspielen/cramfs)

Man sollte drauf achten, dass man unter 4950 kB bleibt !!

wenn das neue cramfs mal über 4950 kb hat und nach dem flashen kein system kommt nehmt einfach bei einer sat box die zuvor beschriebene cables.xml aus dem cramfs raus bzw bei einer Kabel Box umgekehrt und dann funzt es auch wieder man muss oft nur eine ganz geringfügige änderung am cramfs vornehmen und es kommt keine fehlermeldung wie zb kein system zu!

== Bearbeiten eines CRamFS-Images ==

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (ppcboot)"
mtd2: 003e0000 00020000 "root (cramfs)"
mtd3: 00300000 00020000 "emu (jffs2)"
mtd4: 000e0000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Cramfs-Bereich im mtd2, und die Grösse ist $3e0000, bzw. 4063232 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(cramfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln.

Als nächstes holt Ihr Euch mit der DBox selber den Bereich root(cramfs) auf den Linux-PC. Dazu geht Ihr in Menü/Service/Software-Aktualisierung/Experten-Funktion/einzelne Partition auslesen und wählt root(cramfs). Das erstellt ein File in /tmp der Box namens "mtd2.img"; dieses holt Ihr Euch mittles FTP auf Euren Linux-PC !

'''|-----> Alternative:'''

Via telnet/putty mit der DBox verbinden... Ist das Cramfs nun ein mtd2 wie im Beispiel oben, dann folgendes eingeben

cat /dev/mtd/2 > /var/tmp/mtd2.img

Nun liegt das Cramfs mit Namen mtd2.img in /tmp der DBox und kann per FTP auf eurem Computer kopiert werden !

'''<-----|'''

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test
cd test

Nun haben wir ein Verzeichnis "test" angelegt, und dort kopieren wir das "mtd2.img" rein, sowie die beiden beiliegenden Files "cramfsck" und "mkcramfs" ! Dann müssen wir den beiden Files noch Ausführ-Rechte vergeben. Eingabe

chmod +x cramfsck
chmod +x mkcramfs

Nun enpacken wir das "mtd2.img" mit cramfsck... Eingabe

./cramfsck -x outpacked mtd2.img

Da kommt zwar häufig ein "warning: file extends past end of filesystem", aber es passiert nix Schlimmes ;)
Das Verzeichnis "outpacked" muss nicht vorher angelegt werden ! Das übernimmt das Tool cramfsck mit dem Namen als Parameter... Nun nehmt Ihr im Verzeichnis "outpacked" Eure Änderungen vor, und es geht wieder ans ver-cramfs´en ! Folgende Eingabe

cd $HOME/test
./mkcramfs outpacked new-mtd2.img

Auch hier gibts häufig ein "warning: gids truncated to 8 bits (this may be a security concern)", aber auch hier passiert nix wirklich schlimmes ;)
Nun habt Ihr Euer bearbeitetes cramfs, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root(cramfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $3e0000 (4063232 Bytes) gross ! Das von der DBox geholte mtd2.img hat auch eben diese Grösse. Macht man ''' ''ohne Änderung'' ''' gleich wieder ein cramfs draus, dann ist es kleiner ! Warum ? Weil zuvor das ganze Device ausgelesen wurde, auch wenn der beschriebene Datenteil ein kleinerer ist ! Das eben erstellte new-mtd2.img darf '' '''nicht grösser''' '' als die obige Byte-Angabe sein. Es darf aber '' '''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer new-mtd2.img z.B. dann 3854336 Bytes gross, so ist ein "Loch" von 208896 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 4063232 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

== Bearbeiten eines Squash-Images ==

''Als erstes bootet Ihr mal Euren Linux-PC und startet eine Konsole. Dann gebt Ihr mal "mksquashfs" ein. Wenn da ein Error kommt, beendet Ihr die Konsole, loggt Euch als root ein und kopiert das beiliegende "mksquashfs" in /usr/bin/ Eures Linux-PCs ! Durch Eingabe von''

chmod +x /usr/bin/mksquashfs

''vergebt Ihr die Rechte zum Ausführen. Von nun an ist Eurem Linux-PC der Befehl sowohl als root, als auch als user bekannt. Nun loggt Ihr Euch wieder als user in Euren Linux-PC ein...''

Verbindung mit telnet/putty zur DBox herstellen; folgendes eingeben...

cat /proc/mtd

Könnte dann z.B. sowas kommen...

dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "flfs (u-boot)"
mtd2: 000a0000 00020000 "kernel (jffs2)"
mtd3: 005c0000 00020000 "root (squashfs)"
mtd4: 00160000 00020000 "var (jffs2)"
mtd5: 007e0000 00020000 "flash without bootloader"
mtd6: 00800000 00020000 "complete flash"

Hier liegt der Squash-Bereich im mtd3, und die Grösse ist $5c0000, bzw. 6029312 Bytes. Diese Info brauchen wir ! Die folgende Anleitung bezieht sich mal auf dieses Beispiel ! Wenn das root(squashfs) bei Euch in einem anderen Bereich liegt und eine andere Grösse hat, müsst Ihr entsprechend handeln. Als nächstes folgendes eingeben...

mkdir /var/tmp/root

Damit wird erst einmal ein Verzeichniss Namens root in /var/tmp erstellt... Danach folgende Eingabe...

mount -t squashfs -o ro /dev/mtdblock/3 /var/tmp/root

Wenn alles exakt eingetippt wurde, wurde nun der Inhalt vom Squash-Bereich in das Verzeichniss /var/tmp/root gemountet ! Ins Verzeichnis /var/tmp wechseln. Eingabe...

cd /var/tmp <<--- genau *so* eingeben; NICHT in /var/tmp/root wechseln !!!

Nun muss das Ganze "getart" werden, damit die Rechte und Symlinks nicht futsch gehen. Eingabe...

tar -cf root.tar root

Nun liegt das getarte File unter /var/tmp/ und lautet root.tar. Das kann durchaus 15 Megabytes gross sein, denn das Squash-Filesystem ist ja ein Komprimierendes, und nun liegt es unkompimiert, aber ge-tart da ! Via FTP auf den Linux-PC holen... Nun könnt Ihr das root.tar unter /var/tmp wieder löschen und durch Eingabe von "umount /var/tmp/root" das Mount des Squash-Bereiches wieder un-mounten und mit "rm -f /var/tmp/root" das Verzeichnis wieder löschen... Ihr braucht ja für später wieder etwas RAM-Platz !

Weiter geht´s auf dem '''Linux-PC''':

Konsole öffnen... Eingabe:

cd $HOME
mkdir test

Das eben von der DBox2 runtergeladene root.tar in $HOME/test kopieren; dann weiter...

cd /test
tar -xf root.tar

Hiermit wurde es wieder ent-tart. Nun alle Änderungen in $HOME/test/root/.. vornehmen...
Wenn Ihr damit fertig seid, geht Ihr mit "cd $HOME/test" wieder in die Ebene zurück in der sich das /root als Verzeichnis befindet ! Zum wieder ver-squashen gebt Ihr folgendes ein:

fakeroot mksquashfs root mtd3.img -be

Wenn Ihr Probleme mit dem Befehl "fakeroot" haben solltet, dann loggt Euch halt von Anfang an als root in Eurem Linux-PC ein, und die Befehlszeile lautet dann "mksquashfs root mtd3.img -be"... Übrigens steht "-be" für Big-Endian. Nun habt Ihr das root-Image im Squash-Format, welches Ihr dann mittels FTP wieder in die DBox in /tmp uppen und mit den Expertentools einspielen könnt.
(Service/Software-Aktualisierung/Experten-Funktion/Einzelne Partition einspielen/root (squashfs))

'''Anmerkung:''' Wie wir vorhin gesehen haben, ist der reservierte Platz im Image $5c0000 (6029312 Bytes) gross ! Das eben erstellte mtd3.img darf ''' ''nicht grösser'' ''' als diese Byte-Angabe sein. Es darf aber ''' ''durchaus'' ''' kleiner sein !!!! Dann ist halt ein bisschen "luftleerer, ungenutzter" Raum im Image... Ist Euer mtd3.img z.B. dann 5779456 Bytes gross, so ist ein "Loch" von 249856 Bytes im Image... Dieses Loch kann nicht genutzt werden, aber es passiert auch nix Schlimmes; will sagen: es ''' ''muss nicht'' ''' 6029312 Bytes gross sein !!!! Ihr habt also alles richtig gemacht...

= '''Konfiguration der camd3''' =

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
== camd3.config ==

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

== Was bedeutet Boxtyp ? ==

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

== Für was ist der UDP / TCP Port ? ==

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

== Für was ist der Logeintrag ? ==

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

== Was bedeutet LOG_HOST ? ==

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

== Was bedeutete LOG_PORT ? ==

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

== Was bedeutet LOG_FILE ? ==

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

== Bedeutung der Log-Ausgaben: ==

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

== Was bedeuten die Pfad angaben? ==

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

== Was bedeutet DNS cache in Sekunden? ==

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

== Was ist der Multichannel mode ? ==

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

== Welcher slot steht für was? ==

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

== Warum liest die camd3 meine Original Karte nicht? ==

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

== Was ist das Kommando D0,D2 bzw. D3? ==

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

== Wie blocke ich um z.B. mein Abo zu verlängern? ==

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?==

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

== camd3.keys ==

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

== camd3.servers ==
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

== camd3.users ==
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

== Services Datei ==

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:14:42Z

Limette: /* '''Einbau/Update der camd3 ins DBox2-Image''' */

= '''Einleitung/Vorwort''' =

== Was ist die camd3 ? ==

Die camd3 ist ein Smartcard-Emulator für verschlüsselte, digitale TV- und Radiosender. Sie unterstützt aber auch originale Smartcards. Ebenso kann man mit ihr Cardsharing via Heimnetzwerk und via Internet betreiben, und sie unterstützt das Multicam...
== Was heisst denn camd3 überhaupt? ==
CAM steht für "Conditional Access Module", was übersetzt etwa heisst "Modul für bedingten Zugang"... Das Teil ist im Grunde ein Datenfilter, der sich nur dann angesprochen fühlt, wenn tatsächlich die Sprache an ihm vorbeirauscht, die er auch versteht. Das macht er nur für die Smartcard (aufopferungsvoll), weil die sonst so überfordert wäre... Was nun ein MultiCAM sein soll erklärt sich von selbst dann ;-) Kann halt mehr "Sprachen"... Und kann somit auch mit anderen Smartcards umgehen. Super, weil sonst müsste man für jede Originalkarte die mit einer anderen Verschlüsselungstechnik arbeitet, eine Extra-Settopbox kaufen, bzw. ein Extra-CAM (falls das bei dem jeweiligen Receiver überhaupt geht), bzw. ein CI-Modul (Conditional Interface Module; da kann man die Smartcard direkt ins Modul schieben; is aber im Grunde intern dieselbe Technik)

Und dann gibts ja noch die camd... der Daemon zum CAM (deswegen der Name), also ein Stück Software, bzw. eine Software-Schnittstelle zwischen CAM (Hardware) und dem Tuxbox-Betriebssystem (Software). Könnte man vielleicht als "Treiber" fürs CAM bezeichnen. Wenn man in die Dbox2 reinguckt, dann sieht man allerdings nicht viel konventionelles CAM. Nur so ein paar festverlötete Hardwarebrocken. Die "cam-alpha.bin" spielt auch noch als "Treiber" mit (manche sagen es wäre das CAM-an-sich)... Jedenfalls bestimmt die cam-alpha.bin schonmal von wo das Signal kommt (Kabel oder SAT; die entsprechende Version von ihr muss ins jeweilige Image, sonst geht nix). Danach reiht sich der CAM-Daemon ein. Man könnte die camd so manipulieren, dass das interne "CAM" auch andere "Sprachen" durchlässt. Z.B. Seca oder sowas, statt immer nur Betacrypt. Mithilfe eines MultiCAMs geht das hardwareunterstützt mit Originalkarten. Aber was ist, wenn man keine Originalkarte hat ? Geht das auch softwareunterstützt ? Tatsächlich: Das geht ! Nennt sich dann camd-Emulator oder auch Emulator bzw. Emu ! Ohne Keys geht aber nix; also eine Schnittstelle in den Emulator, der dann die zu entschlüsselnden Keys nicht mit der Smartcard aushandelt, sondern mit ein paar Dateien, die sich im Image befinden; also ein Emu-Image ! Jetzt isses aber so, dass diese Emu-camd auch nur eine Software ist, die wieder Libraries und weitere externe Dateien benötigt, die ausserdem nur in bestimmten Pfaden liegen sollen/können/dürfen. Gibt viele Hacker-camds... z.B. camd3, newcamd, gbox, evocamd, mgcamd, etc. Da es privat-geschriebene Tools sind, und es keine Emu-Union gibt *rofl* ist es halt so, dass man jeden Emu irgendwie anders ins Image frickeln muss...

Der CAM-Daemon (camd), der von der offiziellen Tuxbox-Developer-Crew geschrieben wurde, nennt sich camd2 und in den meisten Images ist schon eine camd2 drinnen; jedoch bietet jener (jene ?) keinen Premiere-Support, was soviel bedeutet, dass man zwar eine originale Premiere-Karte in die DBox2 stecken kann, jedoch Premiere dunkel bleibt ! Es sei denn man hat noch die Betanova am Laufen ;-)
Der Grund: Premiere hat dies bei der Tuxbox-Developer-Crew erwirken können, da sie sonst keine Lizenzen für Hardcore-Erotik in Deutschland bekommen hätten. Denn mit der Betanova-Alternativ-Software Tuxbox kann man die Jugendschutz-Sperre umgehen. Deswegen hat die Tux-Crew kurzerhand den [u]gesamten Premiere-Empfang[/u] in ihrer camd2 abgeschaltet !

Wer nun nur Premiere mit einer originalen Premiere-Karte auf einer DBox2 mit Tuxbox-Firmware gucken möchte, muss eine gepachte camd2 einspielen. Oder man spielt sich die camd3 ein, welche das auch kann (neben noch weiteren Features ;-) Zwar zählt die camd3 auch zur Kathegorie "Emu", aber wer auch ein Geplagter ist, der die Betanova-Firmware Schei**e findet, und dennoch Premiere unter Tuxbox-Oberflächen schauen möchte, findet in der camd3 eine Alternative zur gepatchten camd2 ;)

= '''Info über die Image-Arten, und welche Werkzeuge benötigt werden''' =

== Welche Image-Arten gibt es ? ==

Es gibt die unterschiedlichsten Images ! Sie unterscheiden sich idR. erstmal durch 1xI oder 2xI (die Bezeichnung bedeutet, dass eine DBox2 entweder *einen* FlashROM-Baustein hat, oder *zwei* ! Das "I" steht für Intel, welches in den meisten DBoxen verbaut wurde. Es gibt auch AMD-FlashROMs. In dem Fall müsste es eigentlich 2xAMD heissen, aber der Kern-Unterschied liegt nicht am Hersteller, sondern an der Chip-Anzahl...)
Und in diesen FlashROMs kann die Firmware "Tuxbox" (sei es neutrino oder enigma oder both-in-one) in mittlerweile drei Filesystemen stecken. Das sind JFFS2, CramFS und Sqaush. Ersteres ist re-writable, die anderen beiden sind read-only, aber enthalten eine bessere Realtime-Komprimierung als JFFS2 ! Squash die Beste ! Wenn mans genau nimmt, sollte man eigentlich nur noch entweder über Squash, oder JFFS2 nachdenken. Squash weils am besten komprimiert, JFFS2, weils auch re-writable ist ! Wer zwar JFFS2 haben möchte (wegen Beschreibbarkeit), aber mehr Platz braucht, kann sb-shrink zurhilfe nehmen. Mag zwar verwirrend sein, aber in eigentlich jedem CramFS/Squash-Image liegt auch mind. eine JFFS2-Partition. Warum ? Weil dort so Dinge wie Channel-Search, zuletzt geschauter Kanal, oder Auto-Update-Keys irgendwo gespeichert werden müssen, bevor die Box ausgeschaltet wird. Ein JFFS2-Only ist was anderes... Dort ist wirklich *alles* wiederbeschreibbar !
Jedenfalls wenn die camd2 in /bin liegt (was nur innerhalb eines JFFS2-Only-Images beschreibbar ist), dann führt kein Weg am Re-Imaging vorbei. Sofern es sich um ein JFFS2-Only-Image handelt, kann man das weglassen. Aber sobald man z.B. in einem Squash-Image die camd2 ersetzen will, und jene nicht im beschreibbaren Bereich (z.B. /bin) liegt, dann muss halt gebastelt werden, leider ! (wie das geht, wird hier beschrieben)

----

Wichtig wäre es natürlich als Erstes einmal nachzuschauen ob überhaupt noch genügend Platz im Image zur Verfügung steht ! Verbindet Euch mal mit Telnet oder Putty auf eure Box (wie das funktioniert steht gleich darunter) und gebt mal "df" ein. Werte bei knapp 90% sind idR. Ende der Fahnenstange ! Dann müsst Ihr Plugins/Spiele rausschmeissen, sonst gehts nicht ! Oder Ihr müsst anderwärtig aufräumen (z.B. sb-shrink nehmen, etc.). Durch Eingabe von "ps" unter Telnet/Putty sieht man hier schon meistens wie die eingebaute camd heisst und wo sie liegt ! In seltenen Fällen wird nur der Symlink der laufenden camd angezeigt (muss man dann selbst ausfindig machen). Symlinks sind mittels "ls" unter Telnet/Putty idR. unsichtbar !
Eingabe "ls -la" zeigt dann wirklich alles an ! Mittels FTP kann man auch einiges angezeigt bekommen...

Also zuerst benötigt Ihr ein FTP-Programm (für Windows z.B. Total Commander; Download hier http://www.ghisler.com/ ; für Linux gehts auch mit dem Midnight-Commander [mc], der idR. vorinstalliert ist), oder Telnet (Boardmittel unter Windows und Linux) .Telnet lässt sich mit Windows via Start-Button/"Ausführen" aufrufen. Alternative für Windows ist Putty... Download hier http://www.uni-giessen.de/hrz/software/putty/ !!

== FTP-Verbindung zur DBox2 herstellen: ==

Windows: Total-Commander starten. Netz/neue Verbindung/dbox-Namen eingeben (zb "meine dbox"), IP der DBox eingeben; Login "root" und "dbox2" als Passwort (Achtung: Passwort kann auch ein anderes, oder auch ohne PW sein) !! Mit "ok" abschliessen und verbinden !
Linux: Durch Eingabe von "mc" den Midnight-Commander starten. Dann F9 drücken, mit den Cursortasten zu dem Menüeintrag "Links"- oder "Rechts" gehen, "FTP-Verbindung" auswählen und "root@192.168.x.y"(IP der Box) eingeben, und mit Eingabe des Passwortes abschliessen (wenn kein PW, dann einfach ENTER). Als Alternative könnt Ihr auch kbear verwenden - der ist sehr einfach und intuitiv zu verwenden

Jetzt solltet Ihr auf Eurer DBox2 via FTP eingeloggt sein !

== Telnet/Putty-Verbindung zur DBox2 herstellen ==
(Anmerkung: Nur eins der folgenden Varianten wird benötigt !)

Putty: Bei "Host-Name" gebt Ihr die IP der DBox2 ein; darunter auf Telnet klicken (Port 23) und unter "saved sessions" gebt Ihr zb "meine dbox" ein. Dannach auf "save" ! Nun Doppelcklick auf "meine dbox", root/dbox2 (oder Euer eigenes Passwort eingeben)... Nun seid Ihr auch mit Putty auf der DBox2 !!
Telnet unter Windows: Start-Button/Ausführen/Eingabe: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr auch unter Windows mit Telnet auf der DBox2 eingeloggt !
Telnet unter Linux (grafische Oberfläche): Ein Konsolen-Fenster öffnen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !
Telnet unter Linux (Textkonsole): Mittels ALT-F2 auf eine zweite Konsole wechseln (für später: zurück gehts mit ALT-F1). Dort einloggen. Eingabe dort: "telnet (IP der DBox2)", dann root/dbox2 (oder anderes PW, bzw. auch ohne PW)... Nun seid Ihr mit Telnet in der DBox2 eingeloggt !

== Welche Werkzeuge werden noch benötigt ? ==

- mkfs.jffs2, mkcramfs, mksquashfs (je nach Image-Art nur das zutreffende benötigt; liegt alles dem Anhang bei)
- Optional: NewTuxBoxFlashTools (NTBFT) <--- gibts hier in der Database !
- DBox2-Boot-Manager... Hiermit kann man unter Windows Images flashen, aber auch Bootlogs erstellen und Win-Partitionen mounten (und vieles mehr)... (Download: http://dbox.feldtech.com )
- Un-TAR Utilities für Windows zum enttaren von Files ! Kann man machmal brauchen... Auch Files mit .gz und .bz2 Endung sind hiermit unter Windows entpackbar (Download: http://dbox.feldtech.com )
- Linux auf dem PC ! Optional: Eine der vielen Linux-Emulationen unter Windows wie cygwin oder Bochs; oder VMware oder Virtual-PC als "PC-Emulator" für einen PC-im-PC in dem ein Linux unter Windows läuft , etc.
- Optional zum Editieren von Texten unter Windows im Linux-Format: Ultraedit (Download: http://www.ultraedit.com/ )

= '''Einbau/Update der camd3 ins DBox2-Image''' =

Wie bereits erwähnt, ist die camd3 die Alternative zur "offiziellen" camd2 ! Das einfachste wäre nun, einfach die camd3 in camd2 umzubenennen, und im Image unter /bin zu überschreiben. Bei einem JFFS2-Only-Image wär das dann auch schon fast alles. ;) Da aber bei allen anderen Images das Verzeichnis /bin in einem NICHT-beschreibbaren Bereich liegt, sollte man sich was anderes ausdenken...

Jedes Image verfügt über einen beschreibbaren Bereich (JFFS2)... Auch ein Cramfs- oder ein Squash-Image (!) Idee also, die camd3 in den JFFS2-Bereich eines Cramfs/Squash-Images abzulegen !
Was aber machen, wenn das Image beim Booten bereits die "offizielle" camd2 startet und die camd3 hinterher ? Das geht leider nicht... Geht immer nur eins (!) Lüftung des Geheimnisses ist die Datei "start_neutrino" oder "start_enigma" ! Dort könnte man alle Einträge "/bin/camd2" einfach in /var/camd3" abändern ! Fehlt dann nur noch die Konfiguration (detaillierter beschrieben unter Punkt 5.)
Einige Image-Ersteller haben da sogar schonwas vorbereitet; lies´ weiter unter Punkt 3.1. (!)

== Einbau der camd3 (Image ist noch ohne camd3) ==

Wie eben schon beschrieben, haben einige Image-Ersteller schon eine "Schnittstelle" zum Laden einer Alternativen camd[B]X[/B] eingebaut. Schauen wir uns die "start_neutrino" einiger Images mal an...

AlexW-Image (1.7.1)
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;

Yadi-Image
#!/bin/sh
sectionsd
timerd
if [ -e /var/bin/camd2 ]; then
/var/bin/camd2
else
/bin/camd2

JackTheGrabber-Image (JTG)
fi;
/bin/sectionsd
/bin/timerd
/bin/zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2
fi;
fi;

Bits4Fun-Image
zapit
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2
else
/bin/camd2

Das sind jeweils nur ausgeschnittene Teile der start_neutrino... Wie man sieht, wiederholt sich ein Teil dessen in vielen Images... Nehmen wir´s mal unter die Lupe:

Auszug der start_neutrino:
if [ -x /var/bin/camd2 ]; then
/var/bin/camd2
else
if [ -e /var/bin/camd2 ]; then
chmod +x /var/bin/camd2
/var/bin/camd2

Es wird nach einer camd2 im beschreibbaren Teil /var/bin gesucht und wenn eine gefunden wurde, werden die Rechte zum Ausführen vergeben, sofern nicht schon erfolgt; dann wird gestartet !!

else
/bin/camd2

Wenn keine gefunden wird, wird die orginale camd2 aus /bin gestartet (die jedoch ohne Tüfteleien ohne Premiere-Support daherkommt) !!

'''ALLES WAS WIR ALSO NUN MACHEN MÜSSEN, IST DIE CAMD3 IN CAMD2 UMZUBENENNEN UND AN DIE STELLE IM /VAR BEREICH ZU SCHIEBEN, WIE ES IN DER START_NEUTRINO DEKLARIERT WURDE!'''

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... Jene kopiert Ihr dann via FTP nach /var/bin der DBox ! Nun muss sie nur noch umbenannt werden... Zuvor muss aber die laufende camd (sei es die camd2, oder die camd3, oder die in camd2 umbenannte camd3) '''abgeschossen werden''' ''

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd2 (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd2 aus dem RAM gelöscht.

''Als nächstes müsst Ihr das Verzeichnis /var/bin anlegen (falls das Verzeichnis noch nicht existiert)... Der ganze Vorgang incl. /var/bin erstellen hier im Detail...''

'''Windows:''' Via FTP unter /var das Verzeichnis /bin erstellen. Nun in das Verzeichniss /var/bin wechseln und die camd3630 dort reinkopieren; danach in camd2 umbenennen !
'''Linux-"mc":''' Mit TAB auf die "DBox2-Seite" wechseln, in /var wechseln, F7 drücken, "bin" eingeben (erstellt /var/bin), in /var/bin gehen, mit TAB auf die Festplattenseite gehen, F5 drücken (kopiert die camd3630 in /var/bin), mit TAB wieder auf die DBox-Seite wechseln, den Cursor auf camd3630 legen, F6 drücken und eingeben "camd2"+ ENTER (benennt die camd3 um)
'''Telnet/Putty:''' Eingabe "cd /var", dann "mkdir bin", dann mit FTP die camd3630 in /var/bin uppen, dann wieder unter Telnet/Putty Eingabe (unter /var/bin) "mv camd3606 camd2"

Natürlich könnt Ihr diese camd3630 auch *gleich* in camd2 umbenennen und nach /var/bin kopieren; das spart Zeit. Jeder wie er will...

Jetzt geben wir der "camd2" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:
'''Windows-FTP:''' camd2 anklicken im Menü oben auf Dateien/Dateiattribute ändern und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschliesen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3 liegt. Also "cd /var/bin" und gebt dann "chmod 755 camd2" ein !

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt !

'''ALS NÄCHSTES EDITIERT IHR DIE START_NEUTRINO (ODER START_ENIGMA) SO, DASS DIE WEITER OBEN BESCHRIEBENEN PASSAGEN DRINSTEHEN, FALLS SIE NICHT SOGAR SCHON DRINSTEHEN !!!!'''

'''Das Verzeichnis /var/keys anlegen und Konfigs kopieren'''

In der selben Weise wie wir oben /var/bin angelegt haben, erstellen wir noch /var/keys... Und in der selben Weise, wie wir die camd3 (als camd2) ins Image kopiert haben, kopieren wir die Dateien camd3.config, camd3.keys, camd3.users, camd3.servers in '''/var/keys'''!

Wenn wir mit der camd3 Premiere-Unterstützung durch die Originale Smartcard haben wollen, machen wir folgendes:

Wir öffnen die camd3.config (liegt fast bei jedem camd3-Release von doz21 dabei) unter Windows z.B. mit Ultraedit, oder unter Linux mit dem "mc" mittels F4, und ändern z.B. wie folgt (man könnte durch Telnet/Putty auch direkt innerhalb der DBox2 mittels "vi camd3.config" ändern, aber der vi ist umständlich zu bedienen; wer sich auskennt kann den vi aber nutzen ):

'''(ACHTUNG ! NICHT MIT NOTEPAD ODER WORD, ETC. EDITIEREN)'''
''Bei den meisten Dateien ist das zwar egal, aber in "camd3.users" kann es Probleme mit den Passwörtern geben.''

Port=24110
Osd=1
Debug=1
Slot0_Start=0
Slot1_Start=0
Slot2_Start=0
Slot3_Start=1
Slot0_AU_G=0
Slot0_AU_S=0
Slot0_AU_U=0
Slot1_AU_G=0
Slot1_AU_S=0
Slot1_AU_U=0
Slot3_AU_A=1

'''Windows:''' Unter Ultraedit auf Konvertieren/DOS auf Unix gehen und abspeichern !
'''Linux:''' Beim "mc" einfach 2x Escape drücken und die Nachfrage zum Abspeichern mit "Ja" quittieren ! Bei anderen Editoren (z.B. unter KDE) halt eben abspeichern; ein Konvert DOS/Unix nicht erforderlich !

Die Dateirechte müssen Lesezugriff haben. Können auf 644 bleiben (also nicht-ausführbar) !

== Nachdem wir das Binary eingebaut haben kommen nun die Konfigs ==

Da sich ab- und an mal bei den Files was ändert, sollte man in dem entsprechenden Thread von doz21 mal nachlesen, bzw. die meist bei Änderungen von doz21 beiliegenden Beispieldateien mit denen im Image vergleichen... "Hell" wirds natürlich nur mit korrekten Konfigs und korrekten Keys... Genauer wird das unter Punkt 4. erklärt !

== Ein erster Test... ==

Da wir ja vorhin die laufende camd "abgeschossen" haben, werden wir nun mal einen ersten Test der camd3 mittels Telnet/Putty starten:

Einfach (in unserem Beispiel) /var/bin/camd2 eingeben... danach sollte so ein ähnlicher Log erscheinen/kommen...

[camd]: Slot0: deaktiviert
[camd]: Slot1: deaktiviert
[camd]: Slot2: deaktiviert
[camd]: Slot3: aktiviert
[camd]: OSD aktiviert
[camd]: DEBUG aktiviert (mit Verbindungsinformationen)
[camd]: UserDB: USER=benutzer1 PASS=password1 CAIDs=Alle
[camd]: /var/keys/camd3.servers: HOST=192.168.0.7 PORT=24110 : alle CAIDs
[camd]: /var/keys/camd3.users - No such file or directory
[camd]: KeyDB: gestartet
camd !!!STREAMBOARD!!! v3.606 - erfolgreich gestartet

Wichtig ist die letzte Zeile ".....'''erfolgreich gestartet" !''' Wenn die nicht kommen sollte, dann habt Ihr irgendwas falsch gemacht !

Das war es im Groben ! Nun die DBox neu booten... Die orginale Premiere-Karte sollte nun im Originalslot der DBox2 funzen.

In manchen Images (Boxcracker) ist die camd3 unter /emu oder (Zg0re + SB-Image) unter /bin/emu zu finden und heißt evtl. camd3.bin, oder gar camd3.ppc ! Aber es ist fast immer der gleiche Ablauf ! Symlinks nicht ausser Acht lassen !!!

Wer Plugins benötigt um die camd2 (die umbenannte camd3606) zu starten/beenden findet diese im Anhang !
Dieses Plugin kann jederzeit umgebaut werden womit zb der start einer camd3 mit den Namen camd3633.bin möglich ist !!

Wichtig ist, in neueren Versionen der camd3 von doz21 die mitgelieferten Dateien camd3.config, camd3.users camd3.keys, camd3.servers anzusehen da sich dort öfters mal was ändert !

=== Einbau der Dateien "camd3_start", "camd3_stop" und "pcamd" ===

Die Datei '''camd3_start''' dient zum Start von camd3. Zusätzlich wird der Treiber "multicam.o" geladen, der für ein Funktionieren eines erweiterten Kartenlesers in der dBox unabdingbar ist.

Die Datei '''camd3_stop''' dient dazu, die camd3 ordnungsgemäß zu beenden ohne die Keydatei zu zerstören, wie es aus früheren Versionen bekannt ist. Dazu wird nach Aufruf des "kill"-Befehles für camd3 in einer Schleife gewartet, bis sich der Prozess ordnungsgemäß beendet hat.

Zuerst müsst ihr in den Dateien "camd3_start" und "camd3_stop" (editieren z.B. mit Ultraedit) den Namen eurer Camd korrekt eintragen.

Hier dazu ein Auszug der Datein "camd3_stop":

#!/bin/sh

# Diese Zeile ANPASSEN !!!
# Du muss hier den Name von deinem camd eingeben (camd2 oder camd3 oder camd3606 usw.)
CAMD_NAME="camd3" <--- hier ändern

Die Datei '''pcamd''' ist im Gegensatz zu den vorgenannten Scripten ein Binärfile, das ebenfalls für ein korrektes Beenden des "camd3-Prozesses sorgt. Derzeit existiert nur der Aufrufparameter "pcamd -kill". Es macht Sinn, den Aufruf dieses Programmes in die Start-Datei ("start_neutrino" oder "start_enigma") einzuarbeiten, damit auf jeden Fall beim Herunterfahren der dBox camd3 ordnungsgemäß beendet wird und nicht die Datei "camd3.keys" zerschossen wird.

Sinnvollerweise wird z.B. in "start_neutrino" der Aufruf "pcamd" vor der Zeile "pzapit -kill" eingefügt.
Das Ganze sollte dann so z.B. aussehen:

...
/bin/neutrino -u -f
/bin/pcamd -kill
pzapit -kill
...

Danach einfach mit einem FTP Programm auf die D-Box einloggen, und in den Ordner "/var/bin" die Dateien "camd3_start", "camd3_stop" und "pcamd" hineinkopieren, Rechte auf "755" setzen, zuletzt die Dateien "start_neutrino"/"start_enigma" noch anpassen. Siehe dazu auch die Beispieldatei von Doz, die jeder neuen camd3-Version beiliegt.
Nach dem Neustart der Box sollte das Ganze korrekt laufen.

''Die Methode ist zwar schön- und gut, aber in vielen Fällen ist nicht genug Platz in dem bei Cramfs- und Squash-Images zur Verfügung gestellten JFSS2-Bereich ! In solch einem Fall bitte hier weiterlesen (verschiedene Varianten):''

''' ''Bitte unter 4. weiterlesen...'' '''

== Update einer neueren camd3-Version (Image hatte bereits camd3 an Board) ==

Zuerst schaut man mal nach unter welchem Namen hier nun tatsächlich eure camd3 gestartet wird. Dazu gibt es mehrere Möglichkeiten:

- Ihr verbindet Euch mit FTP auf die DBox und sucht in den folgenden Verzeichnissen /var/bin oder /emu nach einer camd3
- Ihr grast das ganze Image nach einer camd3 ab (aufwendig, aber man lernt gleich ein wenig sein Image kennen)
- Ihr Schaut Euch das Plugin an mit dem die camd3 neu gestartet wird !!
- Ihr schaut Euch die start_neutrino an. Meist steht auch da die genaue Bezeichnung und das Verzeichnis !!
- Ihr gebt unter telnet/putty den Befehl "ps -fe" ein, und werdet fündig !!

Anmerkung: Manchmal ist die camd3 auch verlinkt mittels Symlinks (aufpassen). Telnet/putty zeigt die Symlinks an mit "ls -la" an !!

''Angenommen Ihr habt die *brandneue* camd3 aus dem Streamboard runtergeladen, und jene heisst "camd3630"... In Eurem Image heisst die Datei aber "camd3.bin" statt "camd3630" (und liegt in /emu). Kein Problem... wird gleich erklärt...''
'''Anmerkung:''' Die camd3 ist beliebig umbenennbar !!! Nun zu dem Vorgang im Detail:

Ihr öffnet telnet/putty und gebt folgendes ein:

killall camd3.bin (oder wie auch immer sie bei Euch heisst)

Hierdurch wird die camd3.bin aus dem RAM gelöscht. Danach:

rm /emu/camd3.bin

Hiermit wird die camd3.bin auch aus dem FlashROM in /emu gelöscht !

Nun in das FTP-Programm wechseln und Eure neue "camd3630" nach /emu kopieren und dort in "camd3.bin" umbenennen.
Grund: Die bestehenden Plugins funzen weiterhin, und die start_neutrino muss nicht geändert werden !!

Jetzt vergeben wir der "neuen camd3" noch die erforderlichen Rechte. Wenn Ihr nach Attributen schaut, steht dort möglicherweise "644" ! Das ändern wir nun auf 755. Geht wie folgt:

'''Windows-FTP:''' camd3.bin anklicken im Menü oben auf Dateien/"Dateiattribute ändern" und überall Häkchen bei "Ausführen" setzen. Mit "ok" abschließen !!
'''Linux/Windows via Putty/Telnet:''' Mit Telnet/Putty-Konsole dorthin wechseln, wo die in camd3.bin liegt (cd /emu). Dann dort "chmod 755 camd3.bin" eingeben!

Nun sind die Rechte auf 755 (bzw. halt auf "Ausführen") gesetzt!
Ein Neustart der Box kann danach nicht schaden und alles sollte wie zuvor funktionieren halt nur mit neuer Camd3 !

= '''Bearbeiten eines Nicht-Beschreibbaren Bereiches im Image''' =
== Bearbeiten eines CRamFS-Images mit New-Tux-Flash-Tools unter WinXp ==
== Bearbeiten eines CRamFS-Images ==
== Bearbeiten eines Squash-Images ==

= '''Konfiguration der camd3''' =

Folgende Dateien MÜSSEN (neben der binären camd3) in Euer Image:

camd3.config
camd3.keys
camd3.users (muss für Cardsharing auf den Server)
camd3.servers (muss für Cardsharing auf den Client)

Alle Dateien müssen nach /var/keys kopiert werden !!!
== camd3.config ==

Beispieldatei von DOZ21

# Wenn Parameter gebraucht wird - '#' entfernen und eure Werte reinsetzen!!!!!
#
#
#
# Boxtyp(optional): 1-dbox2, 2-dm7000, 3-dm7020, 4-dm500, 5-dm56xx/Triax; Default ist 2
# BOXTYPE=1
#
# UDP Port(optional); Default - 20248
#UDP_PORT=24110

# TCP Port(optional); Default - 0 (TCP-server ausgeschaltet)
#TCP_PORT=24110

# Log(optional): 0 - keine Ausgaben, 1-Datei, 2 - Console, 4 - UDP(syslog), 3 - Console+Datei, 5 - UDP+Datei, 6 - UDP+Console, 7-UDP+Console+Datei; Default ist 2;
#LOG=2

# Host für UDP-logging
#LOG_HOST=192.168.1.1

# Port für UDP-logging(optional); Default ist 514
#LOG_PORT=514

# Logfile
#LOG_FILE=/mnt/hdd/var/log/camd3.log

# DNS cache in sekunden; Default ist 600 sec
#DNS_CACHE=600

# Pfad zum User-File(optional); Default ist /var/keys/camd3.users
#USERS=/var/keys/camd3.users

# Pfad zum Server-File(optional); Default ist /var/keys/camd3.servers
#SERVERS=/var/keys/camd3.servers

# Pfad zum Key-File(optional); Default ist /var/keys/camd3.keys
#KEYS=/var/keys/camd3.keys

# Pfad zum Socket-File(optional); Default ist /tmp/camd.socket
#SOCKET=/tmp/camd.socket

# Multichannel mode (optional): 0-aus, 1-ein; Default ist 0
#MULTI=1

# Kartenslots (anzahl beliebig)
# je eine Zeile für Slot:
# SLOT=devicename:type:au_g:au_s:au_u:port:username:password:deskey
#
# deskey für normale Slots ist optional, aber port,username und password müssen immer angegeben werden!!!
#
# devicename: Pfad (volständig) zum Device, oder Hostname von cardserver(newcamd)
# type: 1-serial, 2-intern(dreamox), 4-cardserver(newcamd)
# au_g: 1-eingeschaltet, 0-ausgeschaltet
# au_s: 1-eingeschaltet, 0-ausgeschaltet
# au_u: 1-eingeschaltet, 0-ausgeschaltet
# port: port
# username: loginname
# password: loginpassword
# deskey: cardserver deskey (14 byte)

# für Dreambox
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Slot oben
#SLOT=/dev/sci1:2:1:1:1:998:slotoben:password2
# Slot unten
#SLOT=/dev/sci0:2:1:1:1:999:slotunten:password3
# Newcamd Cardserver
#SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

# für dbox2
# Serial
#SLOT=/dev/tts/0:1:1:1:1:997:mastercrd:password1
# Multicam
#SLOT=/dev/tts/1:1:1:1:1:998:multicam:password2

# Au für den original Slot der dbox2: 0-aus, 1-an; Default ist 1
#DBOX2_AU=0

== Was bedeutet Boxtyp ? ==

Mit Hilfe des Boxtyp stellt man die verwendete Box ein auf der ihr die camd3 installieren wollt, ändert einfach die Zahl entsprechend der verwendeten Box.

== Für was ist der UDP / TCP Port ? ==

Die Übertragung wird bei der camd3 entweder über das Protokoll UDP oder TCP gemacht. Bei einer der Serverbox legt dies die udp oder tcp_Portnummer fest, unter der der Server auf eingehende Anfragen lauscht. Genau der gleiche muß bei den Clients in der camd3.servers eingetragen werden damit eine Kommunikation ermöglicht wird. Weiterhin wird über den Porteintrag in camd3.config festgelegt, auf welchem Absende-Port der Client seine Anfragen an den Server stellt.

''' Beispiel:'''
Die Serverbox hat Port 20248, Clientbox Port 20250 in der camd3.config und Port 20248 in der camd3.servers stehen.
Der Client sendet nun mit Absendeport 20250 an den Zielport 20248 des Servers. Bei der Antwort ist es umgekehrt. Der Server nutzt Port 20248 als Absender und schickt seine Daten an Port 20250 der Clientbox.

== Für was ist der Logeintrag ? ==

Die camd3 gibt verschiedene Informationen aus die z.B. Informationen über die Cardsharinganfragen und Verarbeitung enthalten.
Dabei gibt es verschiedene Möglichkeiten diese Infromationen anzeigen zu lassen welche mit diesem Eintrag geregelt werden können.

Datei:
Die Loginformationen werden in einer Datei auf der Box gespeichert

Console:
Gibt die Informationen über Telnet aus wenn man die camd3 manuell über Telnet gestartet hat.

UDP:
Die Loginformationen werden über einen UDP Port an eine beliebige IP gesendet und können dann z.B. am PC abgefragt werden.

== Was bedeutet LOG_HOST ? ==

Hier wird die IP Adresse angegeben an welche die Log-Informationen gesendet werden sollen fall UDP als Logart gewählt wurde.

== Was bedeutete LOG_PORT ? ==

Dies regelt den Port über welchen das Log an die zuvor eigestellt IP gesendet wird.

== Was bedeutet LOG_FILE ? ==

Hiermit wird der Speicherort der Logdatei angegeben fall Datei als Logart gewählt wurde.

== Bedeutung der Log-Ausgaben: ==

00 - ECM (request)
01 - ECM (response)
02 - EMM (für client - set EMM, für server - EMM data) -> veraltet, bleibt aus Kompatibilitätsgründen
03 - ECM (cascading request)
04 - ECM (cascading response)
05 - Kartendaten zum Client (eingehend beim Client)
06 - EMMs (eingehende EMM-Daten beim Server)

'''Normales Sharing Client - Server:'''
172.16.0.121 = Client
172.16.0.123 = Server

'''Auf dem Server eingehende Anfrage:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 ) decoded on /dev/sci1
die Antwort des Servers auf dem Client:
Oct 5 00:54:28 camd3: UDP 01 -> 1702:000000:100A:000A 0.002755s from 172.16.0.123 ( User1 )

'''Sharing mit kaskadierten Servern:'''
172.16.0.121 = Client
172.16.0.123 = 1. Server
172.16.0.124 = 2. Server

'''Anfrage des Clients beim 1. Server:'''
Oct 5 00:54:26 camd3: UDP 00 -> 1702:000000:100A:000A 0.286008s from 172.16.0.121 ( User1 )
'''Anfrage des 1. Servers bei einem 2. Server'''
Oct 5 00:54:28 camd3: UDP 03 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User2 ) decoded on /dev/sci1
'''Antwort des 2. Servers an den 1. Server:'''
Oct 5 00:54:30 camd3: UDP 04 -> 1702:000000:100A:000A 0.286008s from 172.16.0.124 ( User2 )
'''Eingehende Anwort beim Client:'''
Oct 5 00:54:32 camd3: UDP 01 -> 1702:000000:100A:000A 0.286008s from 172.16.0.123 ( User1 )

== Was bedeuten die Pfad angaben? ==

Die camd3 nimmt an, dass die key, server und user Dateien sich im Ordner var/keys befinden, falls dies jedoch nicht der Fall sein sollte kamm man hier den Ort angeben an dem sich die Dateien befinden.

== Was bedeutet DNS cache in Sekunden? ==

Hiermit kann man die Zeit in Sekunden einstellen in welchen Abständen DNS aktualisiert werden soll.

== Was ist der Multichannel mode ? ==

Die camd3 ab Version 3.800 unterstützen den Multichannel mode, dabei kann man z.B. einen verschlüsselten Kanal aufnehmen und dennoch weitere verschlüsselte Sender auf dem gleichen Transponder entschlüsseln.
Der Eintrag MULTI aktiviert oder deaktiviert diese Funktion.

== Welcher slot steht für was? ==

'''DBox2:'''
/dev/tts/0 externe com mit Cardreader
/dev/tts/1 Multicam

Ab camd3.807 wird wieder der original Slot der dbox2 unterstützt, dieser ist immer aktiviert, er wird nicht über die Config geregelt. Er kann nicht für CS genutzt werden.

'''Dreambox:'''
/dev/tts/0 externe com mit Cardreader
/dev/sci0 unterer Slot
/dev/sci1 oberer Slot

Des weiteren gibt es noch die Möglichkeit sich mit der camd3 am Newcamd Cardserver anzumelden um auf dessen Karten zuzugreifen, dies geschiet mit dem Eintrag:
SLOT=localhost:4:1:1:1:22222:dummy:dummy:0102030405060708091011121314

== Warum liest die camd3 meine Original Karte nicht? ==

Eine Möglichkeit wäre, dass ihr vergessen habt den entsprechenden Slot in der camd3.config zu aktivieren, überprüft also ob die # vor dem Slot entfernt ist.

== Was ist das Kommando D0,D2 bzw. D3? ==

D0 -> G=Global -> Globale Kommandos an alle Karten
D2 -> S=Shared -> Shared Kommandos an die eigene Kartengruppe
D3 -> U=Unique -> Unique Kommandos nur an die eigene Karte

== Wie blocke ich um z.B. mein Abo zu verlängern? ==

Um die Karte zu blocken müßt ihr das Autoupdate der Karte deaktivieren, dies geschiet in der SLOT Zeile:

SLOT=/dev/sci0:2:'''1:1:1''':999:slotunten:password3

Ändert dazu die fetten Zahlen 1:1:1 in 0:1:0 und die Karte wird nur noch D2 Zeitverlängerungskommandos erhalten und ist somit geblockt.

Falls ihr die Smartkarte im original Schacht der dbox2 verwendet und diese blocken wollt müßt ihr überprüfen ob der Eintrag:

DBOX2_AU=0

aktiviert und auf 0 gesetzt ist. Damit ist die Karte geblockt.

== Welchen Sinn machte es, bei der Multicam und dem com-Port nochmal in G,U und S zu unterteilen?==

Weil es eben "Sinn" macht entweder nur D0, D2, D3 oder eben auch "alles" durchzulassen!
So kann man regelt ob man nur Kommandos speziell für seine Karte durchlassen will oder auch Globale Kommandos.

== camd3.keys ==

Beispieldatei von DOZ21

#
# Eine Zeile - Ein Eintrag, der so aussehen muss:
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:[-]E............
# oder so:
#
# [-]AAAA:BBBBBB:CCCCCCCCCC:DD:FILE=filename:OFFSET=0xXXXX:SIZE=0xYYYY
#
# AAAA - caid
# BBBBBB - provider
# CCCCCCCCCC - ppua
# DD - keynr
# EEE...... - data
# X - offset
# Y - SIZE
# wenn '-' vor caid -> wird das Keys aus DB gelöscht(wenn vorhanden)
# wenn '-' vor data -> wird das Datateil bytesweise rotiert
#
# oder SO:
#
#
# Für OP.keys muss provider 0000000000 sein

# Beispiel Seca
0100:0000A8:0000000000:0C:1234567890ABCDEF
0100:0000A8:0000000000:0D:1234567890ABCDEF
0100:0000A8:0000000000:0F:1234567890ABCDEF

# Beispiel Conax
0B00:000000:0000000000:E0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B0:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:E1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....
0B00:000000:0000000000:B1:1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1
234567890ABCDEF1234567890ABCDEF1234567890ABCDEF.....

# Beispiel Nagra
1800:007001:0000000000:00:6FF06F47E957D3C8
1800:007001:0000000000:01:BD422C6AD2B58C24
1800:007001:0000000001:00:... - PK0_E1
1800:007001:0000000001:01:... - PK0_N1
1800:007001:0000000001:02:... - PK2_E1
1800:007001:0000000001:03:... - PK2_E1
1800:007001:0000000001:04:... - PK_N2
1800:007001:0000000001:05:... - EMMK1

# Beispiel Via2
0500:015000:0000000000:08:11223344556677881122334455667780

# Beispiel AES
0500:007C00:0000000000:80:11223344556677881122334455667781
0500:007C00:0000000000:81:11223344556677881122334455667782
.....
0500:007C00:0000000000:8A:1122334455667788112233445566778

# Beispiel BISS AAAA - service id (hexadizimal)
2600:00AAAA:0000000000:00:112233445566

# Beispiel ConstandDW AAAA - service id (hexadizimal)
0100:00AAAA:0000000000:00:11223344556677881122334455667788

Die Datei "camd3.keys" muss zwingend !! ins Verzeichnis /var/keys. Grundsätzlich könnte man dort auch einen symbolischen Link anlegen, der auf eine in einem anderen Verzeichnis abgelegte "camd3.keys" zeigt. Spätestens nach der Aktualisierung der Datei durch eine Autoupdate eines Senders wird allerdings der Link gelöscht und die Datei in /var/keys abgelegt.

== Heimnetz-Sharing/Internet-Sharing ==

== camd3.servers ==
(wird nur in der Clientbox benötigt)

Beispieldatei von DOZ21

# cs357x - UDP
# cs378x - TCP
#
# Sende alle ECMs
#cs357x://benutzer1:password1@132.23.78.133:32897
#
# Sende gefiltert nach Services (z.B nur Start und Film)
#
#cs357x://benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services@www.myhost.com:16663
#
#
#
# Sende alle ECMs via TCP
#cs378x://benutzer1:password1@132.23.78.133:32897

'''Via LAN:'''

cs357x:// => UDP-Protokoll
cs378x:// => TCP-Protokoll

benutzer1:password1 => name und passwort zur authentifizierung am Server

Hier ist ein Filter nach Services gesetzt:
:SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services

IP und Port des Servers; Client und Server regeln voll automatisch welche Anfragen per CS gesendet werden und welche nicht:
@132.23.78.133:32897

Der eingetragene Port muß identisch sein mit dem Port aus der "camd3.config" der Serverbox.

Die rausgehende Anfragen kann man einschränken, in dem man z.B. ":SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services" hinter dem Passwort anhängt, somit lässt er z.B. nur Anfragen raus die vorher in der services Datei eingetragen wurden. Damit kann man manuell den Netzverkehr reduzieren, da z.B. eine Anfrage für einen Kanal, welcher nicht in der Services Datei steht,erst gar nicht an den Server geschickt wird, sondern rein lokal über den passenden Key in der Datei "camd3.keys" beanwortet wird, falls möglich.

'''Via Internet:'''

Sieht die camd3.servers genauso aus, man muss nur die Netzwerk-IP durch eine Internetadresse ( zB. www.myhost.com ) ersetzen.

== camd3.users ==
(wird nur in der Serverbox benötigt)

Beispieldatei von DOZ21

# Alle services erlaubt, IN_CASC erlaubt, OUT_CASC erlaubt
benutzer1:password2

# REMM
#benutzer1:password2:REMM=/dev/sci1 (kann auch mit FROM und(oder) SERVICES benutzt werden)

# nur Start
#benutzer2:password2:SERVICES=/var/keys/pw_start.services

# nur Fim
#benutzer3:password3:SERVICES=/var/keys/pw_film.services

# nur Start UND Film
#benutzer3:password3:SERVICES=/var/keys/pw_start.services&SERVICES=/var/key
s/pw_film.services

# Cascadingungsabfragen von benutzer5 werden akzeptiert und local bearbeiteit, wenn es in services steht
#benutzer5:password5:SERVICES=/var/keys/pw_start_in

# Cascading für benutzer6 aktiviert
#benutzer6:password6:SERVICES=/var/keys/pw_start_out.services

#Cascadingungsabfragen von benutzer7 werden akzeptier, local bearbeiteit und anderen Server weitergeleitet
#benutzer7:password7:SERVICES=/var/keys/pw_start_all.services

# Nur Anfragen von einer bestimmten IP-Adresse sind erlaubt (kann auch mit REMM und(oder) SERVICES benutzt werden)
#benutzer8:password8:FROM=sein.hostname.tv
#benutzer9:password9:FROM=192.168.1.210

# DISABLE=1 -> Sende Disable-Service, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=1&SERVICES=/var/keys/pw_start.services

# DISABLE=2 -> Sende Fake-DW, wenn nicht in Service-List (kann mit Anderen Parameters kombiniert werden)
benutzer110:password10:DISABLE=2&SERVICES=/var/keys/pw_start.services

'''Hinweis:''' Bei der dbox2 kan man nur mit multicam bzw. Cardreader und geladenem "multicam.o" Modul einen Server mit Cardsharing betreiben.
Grundsätzlich kann "camd3" auch ohne Cardsharing Server für jegliches Cryptsystem spielen. So ist es denkbar, dass in einem lokalen Netz eine Box Server für andere Boxen spielt, aber keine Karte shared. Dies erspart z.B. Arbeit beim Pflegen der "camd3.keys", da man nur auf einer Box die Datei pflegen muss.

In der camd3.user sind die freigegebenen Clienten, welche mit "camd3" kommunizieren dürfen.

benutzer1:password2 => alle eingehenden Anfragen von den Clienten werden von camd3 angenommen

'''Filtern mit Service Dateien'''

SERVICES=/var/keys/pw_start.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

SERVICES=/var/keys/pw_start.services&SERVICES=/var/keys/pw_film.services => Dem User wird nur erlaubt Sender zu sehe welche in der pw_start.services UND der pw_film.services Datei eingetragen sind.
Alle anderen Anfragen werden von der camd3 ignoriert.

'''REMM - Remote EMM'''

Über diesen zusätzlichen Parameter in der Datei "camd3.users" wird gesteuert, von welchem Benutzer Auto-Update Daten für die Karte die geshared wird angenommen werden.

'''Hinweis:'''
REMM funktioniert zur Zeit nur bei Verwendung des UDP Protokoll, also wundert euch nicht wenn bei TCP keine Kartenupdates per REMM kommen ;)
Des weiteren funktioniert REMM bis jetzt nur mit Irdeto (und seine Abarten, also Betacryt oder getunneltes Nagar) Seca und seit 3.812 mit Cryptoworks.

Es gibt folgende Einstellungen:

DBox2:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/tts/1 => remote EMMs gehen an das Multicam = Karte im Multicam der dBox2

Dreambox:
REMM=/dev/tts/0 => remote EMMs gehen an den seriellen Port = Karte im externen Kartenleser
REMM=/dev/sci1 => remote EMMs gehen an den oberen Slot = Karte im oberen Slot der Dreambox
REMM=/dev/sci0 => remote EMMs gehen an den unteren Slot = Karte im unteren Slot der Dreambox

Das Senden von Remote-EMMs muss beim Client nicht extra aktiviert werden.

Bei korrekter Konfiguration liefert der Server nach der ersten Verbindung seine Kartendaten (HEX-Seriennummer) an den Client, dieser filtert anhand der übermittelten Kartendaten die zutreffenden EMMs aus dem Datenstrom heraus und übermittelt die Daten an den Server. Dort werden je nach AU-Konfiguration D0, D2 oder D3 an die Karte weitergeleitet.

Bei erfolgreicher Weiterleitung schickt der Server eine "Quittung" an den Client.

Wenn man die Logausgabe aktiviert hat, sieht man folgende Sequenzen im Log:

"Paket von .... CMD=05 ..." => beim Client eingehende Kartendaten
"Paket von .... CMD=06 ..." => beim Server eingehende EMMs

Im Erfolgsfalle protokolliert der Server folgendes:
"Oct 5 01:18:26 camd3: emm D0 auf Slot /dev/tts/1 erfolgreich" ( ... oder D2 bzw. D3)

'''Was ist cascading'''

Wenn ihr einen Server betreibt, welcher eine CW-Anfrage eines Clients nicht beantworten kann (da er die nicht entschlüsseln kann), kann die Anfrage an einen anderen Server weitergereicht werden (der muss sich dann in camd3.servers befinden). Die Anfrage kann maximal 3 mal an einen anderen Server weitergereicht werden. Seit der Version 3.668 wird Cascading User-bezogen gesteuert, d.h die Berechtigungen werden einzelnen Benutzern erteilt

Falls keine weiteren Parameter bei einem User angegeben sind ist Cascading in & out für diesen User aktiviert.
Falls man für einen User Cascading regeln will muss man eine Services Datei für diesen Anlegen und dem Usernamen zuweisen s.o.
Das Cascading selber wird dann in der services Datei geregelt.

== Services Datei ==

Beispieldatei von doz21:

[QUOTE]
# AAAA:BBBBBB:CCCCCC:D:E
#
# AAAA caid
# BBBBBB provider
# CCCC service
# D IN_CASC (1-ja, 0-nein)
# E OU_CASC (1-ja, 0-nein)
#
#
#
# Start
1702:000000:0008:0:0
1722:000000:0008:0:0

1702 & 1722 => Sind die ChannelIDs, hier Premiere für Sat und Kabel.

000000 => Ist der Provider

0008 => ist der Services oder anders gesagt die Hex des Kanals. 0008 steht z.B. für Premiere Start.
Mit dem Eintrag FFFF als Platzhalter werden alle Services aktiviert, so dass nicht alle Sender einzeln eingetragen werden müssen (seit 3.812)

0:0 => regelt das Cascading In und Out. 1 erlaubt dem User Cascading 0 unterbindet dieses.

Die Anfragen können nicht beliebig oft weitergeleitet werden, da sonst irgendwann der Traffic zu groß wird. Der Server der die Anfrage weiterleitet wird muss einem Zugriff erlauben. (Der Client muss also dort in der camd3.users eingetragen sein).
Weiterhin muss natürlich der weiterleitende Server selbst als Client bei einem anderen Server eingetragen sein.

"IN_CASC" und "OUT_CASC" muss nur bei weiterleitenden Servern hinter dem 1. Server aktiviert sein. Beim 1. Server muss nur OUT_CASC aktiviert sein, da die eingehende Anfrage des Clients eine "normale" Anfrage ohne Cascading-Kennung ist. Beim Client selbst müssen keine Cascading-Parameter aktiviert sein, da dieser ja nur eine Anfrage an "seinen" Server stellt und eine normale Antwort erhält. Beim letztendlichen Server, der die Anfrage beantwortet, muss nirgends mehr "OUT_CASC" stehen, da er nicht mehr weitere Server befragt, mindestens eine Nutzerkennung muss aber "IN_CASC" aktiviert haben, da sonst Kaskadeanfragen nicht bearbeitet werden.

Beispiel:
Ein Client möchte ein Programm sehen, das der Server nicht entschlüsseln kann, dann gibt er(der Server) die Anfrage weiter an einen anderen Server, wo er (der erst angefragte Server) vorher als Client eingetragen wurde. Dieser entschlüsselt dann das Signal und schickt es, über den erst angefragten Server, an den Client zurück.

'''Verschlüsselung:'''
Weiterhin wird die Kombination aus Username und Passwort zur Generierung eines Verschlüsselungsstrings genutzt. In den aktuellen Versionen von camd3 wird die Übertragung zwischen Client und Server immer verschlüsselt. Vor allem beim Cardsharing über das Internet ist dies mit Sicherheit von Interesse. Bei der Vorgängerversion musste noch ein Schlüssel "von Hand" eingegeben werden und die Verschlüsselung konnte auch abgeschaltet werden. Wenn die Kennungen auf Client- und Serverseite nicht übereinstimmen ist es nicht nur so, dass der Server wegen fehlender Berechtigung keine Antwort gibt, er kann die Anfrage erst gar nicht "verstehen".

= '''Nachtrag/Credits/Dateianhang:''' =
== Top 10 der Fehler, die gemacht werden... ==

# Die neue camd3 getauscht, aber die neuen Config-Dateien nicht ! Z.B. stehen in der camd3.servers der camd3.570 vorne
"cs357x://....", in der älteren camd3.servers aber z.B. noch "cs353x://...." Das muss schon passen !
# Respektive zur camd3.servers muss auch die camd3.users passen wenn ihr euch zu einer anderen Serverbox verbinden wollt. Passend zum obigen Beispiel würde dann dies hier reichen

benutzer1:password1

Anmerkung: Da muss man nichtmal die Wörter tauschen ! Der benutzer1 kann ruhig auch so heissen, warum
nicht !? Dasselbe mit seinem Passwort "password1" ;)
# Falsch editiert ! Mann sollte drauf achten, dass man grundsätzlich einen Unix-Editor benutzt, und nicht das "Notepad" von
Windows, oder Word benutzt... Schliesslich läuft auf der Dbox2 ja das Unix-kompatible Operating System "Linux"
(Problem tritt de facto nur bei "camd3.users" bei Einträgen ohne Filter auf, aber sollte man aus Prinzip tun.)
# Image voll ! Sowohl bei JFFS2-Only Images, als auch bei Cramfs/Squash-Images kann ein Tausch der "libc.so.6" und der
"libcrypto.so.0.9.7" das Image zu voll werden (ein Problem älterer camd3-Versionen)... Dann geht NIX mehr ! Also mächtig freischaufeln.. Z.B. Spiele rausschmeissen.
Bei einem Fehlversuch und nachdem die Message kam "no space left" hilft meist auch kein manuelles entleeren mehr. IdR ist
das Image dann komplett futsch und muss erst nochmal neu geflasht werden ! Erst danach neuen Versuch wagen.
# Nix geht ! Geht mal mit telnet auf die Dbox2 und schaut mal was die Eingabe von "kill -9 camd3", oder "kill -term camd3", oder "killall camd3" ergibt... Wenn da steht, das es nix zum killen gäbe, hat die camd3 niemals richtig gestartet... Ein manuelles Starten der camd3 durch Eingabe von "/var/keys/camd3" kann da schon so manche üerrraschende Hinweise ausspucken...
# Alles okay, aber nix wird hell ! Nun, vielleicht vergessen die camd3.keys zu füllen, oder gefüllt zu kopieren ? Übrigens kann
man die "camd3.key" und "camd3.key1" nun vergessen; die waren in älteren Versionen... Nun heisst sie "camd3.keys"
Dafür kann man aber durchaus die alte camd3.key in camd3.keys umbenennen - das geht (bis auf ein paar Änderungen abgesehen) !
# Dennoch geht nix ! Rechte vergeben ? Macht doch einfach mal mit telnet in dem Verzeichnis in dem die camd3 liegt "chmod +x camd3", dann kann sicher nix mehr anbrennen ;)
# Und immer noch geht nix ! Vielleicht die Keys von einer anderen camd (emu) einfach in die camd3.keys kopiert ? Die hat ihr
eigenes Format... Bitte unter Linux, oder im Win mittels Unix-Editor passend um-editieren !
# Mein unter Linux neu erstelltes jffs2.img oder cramfs.img hat 8257536 Bytes (bzw. typische Grössen für das jeweilige mtd).
Warum lüppt es dennoch nicht ? Es kann durchaus sein, dass so eine Datei zwar die passende Dateigrösse hat, aber dennoch
zu gross ist (vielleicht wurde bei Erreichen der Grösse abgeschnitten ? Bzw. ein JFFS2-Only braucht um zu funzen ein bissie
Rest-Platz zur eigenen Verwaltung... Ca. 500 KByte sollten *wenigstens* frei bleiben !)... Als Tipp hier nur: Ausprobieren !
# Nix geht bei Cardsharing ! Die Konfiguration richtig gemacht und die richtigen Files in die jeweilige DBox2 geuppt ? Die Datei camd3.users muss auf die Server-Box, die camd3.servers muss auf die Client-Box. Wenn Cascading betrieben werden soll, muss zum Betrieb auch auf eine Server-Box eine camd3.servers und auf eine Client-Box eine camd3.users ! Cascading bedeutet, dass eine Kette von Boxen sich jeweils aushilft, je nachdem welche Box welche Antwort liefern kann... Demnach ist jede Box in dem Verbund sowohl mal Client, als auch mal Server !
Tipp zum Austauschen der libc.so.6 und libcrypto.so.0.9.7 im JFFS2-Only (ältere Versionen der camd3)... Mit FTP in /tmp uppen... Dann mit telnet auf die
Dbox2 gehen, und mit "cd /var/tmp" dorthineinwechseln... Dann dort eingeben "mv libc.so.6 /lib"... Dann abwarten !!! Kann
sein, dass da sekundenlang *nichts* passiert... Wenn der Prompt zurückkommt, dann wars erfolgreich !

PS: Wer will, kann die Top10 auch gerne in Top20 erweitern 8)

== Moral von der Geschicht´ ==

Beachtet, dass eine Smartcard zwar im Besitz des Abonnenten ist, aber der Provider/Programmanbieter der Eigentümer bleibt. Ihr solltet also wissen was Ihr damit tut.
Man kann es allerdings keinem Abonnenten verbieten, "seine" Smartcard mit zu einem Kumpel zu nehmen (der z.B. auch eine Box hat, aber kein Sport-Abo besitzt) um dort mit der Karte ein Fussballspiel anzuschauen. Etwa ähnlich verhält es sich bei dem Cardsharing. Sowohl bei Heimnetz- als auch bei Internetsharing bleibt die Karte zu Hause im Receiver, und die Verbindung auf Eure Box ist im Grunde nur so eine Art "Verlängerungskabel" auf Eure Smartcard ;)

Ohne gültiges Abo macht Ihr Euch strafbar !

Gegen ein einzelnes Sharing einer Doku, eines Spielfilms etc. wird keiner was sagen. Wird mit dem Feature des Cardsharings z.B. Brummiere regelrecht *ausgenutzt*, und im übelsten Fall in der halben Strasse für "lau geglotzt", dann entspricht das in keinster Weise den Vorstellung der Autoren des Tools/dieser Anleitung, der Tester und dem Team dieses Boards !
Weniger "schlimm" finden wir es allerdings mit den Emu-Funktionen einen Sender aufzumachen, der in Eurem Land gar nicht abonnierbar ist. Das ist zwar trotzdem untersagt, aber .... ;) Die camd3 ist auf keinen Fall eine End-Anwender-Software, sondern ist und bleibt eine Technik-Demonstration, an der stetig entwickelt wird.

Diese Anleitung soll sowohl den erfahreneren User, als auch den Newbee ansprechen. Man kann sich entweder alles komplett durchlesen, oder es auch als "Nachschlagewerk" nutzen, und nur diese Infos entnehmen, an denen man grade knabbert... Viel Erfolg beim Einbau der camd3 !

== Credits ==

Wenn hier irgendwo Fehler enthalten sein sollten, verbessert sie, und gebt Bescheid (an einen der Autoren) ! Es wird dann eingepflegt...
Hier ist die Anlaufstelle... [http://streamboard.gmc.to/wbb2/thread.php?threadid=15858&sid= Fragen, Anregungen zu 'HowTo Anleitung camd3']

Grosses Dankeschön an das Streamboard, und an doz21 für seine unermüdliche Arbeit an der camd3, und an alle, die das Board zu dem machen was es ist.

Gewidmet an: doz21

Erstellt von: imbécil, limette,murphy, tom_63, zor und Just_Me

© 2004 und 2005 by Streamboard

'''Was ist im Dateianhang enthalten?'''

- cramfsck
- mkcramfs
- mkfs.jffs2
- mksquashfs
- camd3-Plugins
- dieses HowTo im .doc, .pdf und .html - Format zum OFFLINE lesen
- ein "Erste-Hilfe-Paket" als HTML-Dokument zur Konfiguration der camd3

Update --> Dateianhang 30.06.04, 23.50 Uhr (waren Verlinkungsfehler im "Erste-Hilfe-Paket"); 26 Downloads bis dahin.
Update --> 03.07.04, 17.00 Uhr - Ergänzung "Was ist debug" unter Punkt 5 (tom_63) ! Entsprechendes Update der Offline-Dokumente im Dateianhang (tom_63) ! Update des "Erste Hilfe-Pakets", ebenso 03.07.04 (zor); 322 Downloads bis dahin..
Update --> Dateianhang 08.11.04, 00.05 Uhr (Updates, in Punkt 5. und Punkt 3. - Edits von imbécil und tom_63, Dateianhang von tom_63); 1672 Downloads bis dahin...
Update --> Dateianhang 29.01.05, 22.00 Uhr; Stand vom 17.01.05 (Updates in Punkt 5. und 6. - Edits von tom_63 - Das HowTo auf den aktuellen Stand der camd3.681 gebracht); 828 Downloads bis dahin...
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 22.10.2005 (PDFs folgen noch - TOM)
Ersetzen von Kapitel 5 nach einer Überarbeitung von Just_Me am 27.12.2005 (Anpassen nach Version 3.830)
30.12.2005 Dateianhang aktualisiert (1672 + 2010 Downloads bis dahin)

Stand: Dezember/2005

HowTo - Anleitung Camd3

2006-10-24T22:02:01Z

Limette: /* '''Nachtrag/Credits/Dateianhang:''' */

HowTo - Anleitung Camd3

2006-10-24T21:50:53Z

Limette: /* Services Datei */

HowTo - Anleitung Camd3

2006-10-24T21:50:02Z

Limette: /* '''Konfiguration der camd3''' */

HowTo - Anleitung Camd3

2006-10-24T21:49:44Z

Limette: /* '''Nachtrag/Credits/Dateianhang''' */

HowTo - Anleitung Camd3

2006-10-24T21:49:28Z

Limette: /* '''Nachtrag/Credits/Dateianhang''' */

HowTo - Anleitung Camd3

2006-10-24T21:49:15Z

Limette: /* Einbau der camd3 (Image ist noch ohne camd3) */

HowTo - Anleitung Camd3

2006-10-24T21:48:19Z

Limette: /* '''Services Datei''' */