« Archives in April, 2011

CrystalHD, Libcrystalhd und Gstreamer Plugin in Ubuntu kompilieren

Da mein neues Wetab ja ein schönes Broadcom CrystalHD Modul drin hat, würde ich das natürlich gerne vollständig in Ubuntu nutzen, was ich nun auch endlich geschafft habe, einschließlich des Gstreamer Plugins u.a. für den Totem Video Player.  8-)

Da ich Ubuntu 10.10 auf dem Wetab nutze, sollte das analog auf anderen Devices funktionieren.

Ubuntu 10.10 bringt ebenfalls ein eher beschissenes crystalHD Modul bereits mit, dieses müssen wir zwangsläufig ersetzen.

Aber zu erst alle Abhängigkeiten installieren:

sudo apt-get install checkinstall git-core autoconf build-essential subversion dpkg-dev fakeroot pbuilder build-essential dh-make debhelper devscripts patchutils quilt git-buildpackage pristine-tar git yasm zlib1g-dev zlib-bin libzip-dev libx11-dev libx11-dev libxv-dev vstream-client-dev libgtk2.0-dev libpulse-dev libxxf86dga-dev x11proto-xf86dga-dev git libgstreamermm-0.10-dev libgstreamer0.10-dev automake

Nachdem das alles installiert und erledigt ist, legen wir los:

git clone git://git.wilsonet.com/crystalhd.git
cd crystalhd/driver/linux
autoconf
./configure
make
sudo checkinstall --fstrans=no

Hierbei kommt ein Fehler, weil wir das Kernel Modul überschreiben wollen. Checkinstall hat uns (je nach gewähltem Namen) das Package erstellt, welches irgendwie .deb heißt (zur not mit ls | grep .deb rausfinden). Dieses installieren wir daher so:

sudo dpkg -i --force-overwrite .deb

Danach geht es weiter mit dem kopieren der Firmware und dem Kompilieren+Installieren von libcrystalhd:

sudo cp ../../firmware/fwbin/70015/* /lib/firmware/
cd ../../linux_lib/libcrystalhd
make
sudo checkinstall --fstrans=no

Jetzt sind wir an einem Punkt, an dem das crystalhd Modul bereits in Youtube(Flash!) funktionieren sollte, sobald wir folgendes machen:

sudo modprobe crystalhd

Damit das Modul immer automatisch geladen wird, fügen wir es ans Ende von /etc/modules an.
(echo crystalhd >> /etc/modules als root).

Prüfen ob es korrekt geladen wurde, kann man mit dmesg | grep crystal, dabei sollte dann sowas rauskommen:

[    5.029199] Loading crystalhd v3.10.0
[    5.029249] crystalhd 0000:02:00.0: Starting Device:0x1615
[    5.029284] crystalhd 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    5.034739] crystalhd 0000:02:00.0: irq 43 for MSI/MSI-X
[    5.276152] crystalhd 0000:02:00.0: setting latency timer to 64

Sobald man nun ein crystalhd-beschleunigbares Video in Youtube/Flash ansieht, erscheint zusätzlich folgende Zeile:

[ 1772.346897] crystalhd 0000:02:00.0: Opening new user[0] handle

Übrigens funktioniert das auch mit 360p,480p und 720p Videos und nicht nur mit 1080p.

Nun wollen wir das ganze natürlich auch in Totem nutzen, daher kompilieren wir kurz noch das Gst-Plugin, Abhängigkeiten dafür haben wir schon installiert. (Das hat ganz schön gedauert bis ich herausgefunden habe wie es genau geht, da es echt viele Config Files usw. in dem Ordner gibt, die in Frage kämen und die Readme Datei alles andere als hilfreich ist.)

 cd ../../filters/gst/gst-plugin/
./autogen.sh
make
sudo checkinstall

Es kann sein das ich Abhängigkeiten vergessen habe, die Fehler sollten aber euch mitteilen was fehlt, zumindest soviel, dass es dann zum Googeln reicht  ;-)

Starten wir nun ein entsprechendes Video in Totem, sollte ebenfalls so ein Output wie oben bei einem Flashvideo in dmesg erscheinen. (Man merkt auch schnell, wenn 1080p Videos plötzlich mit relativ geringer Last flüssig laufen..)

Den ersten Teil hab ich größtenteils aus dem Beitrag von Catscrash in der Wetab-Community übernommen, danke für diese Infos! (Ich habe allerdings den Mplayer weggelassen. Braucht man nicht, wenn Totem es tut.)

Besucht auch die WeTab-Community und The Wetab Blog. Eigentlich die 2 besten Anlaufstellen für “WeTabber”!

Eine Anmerkung noch: Mit VLC geht das leider nicht, da dieser keine GStreamer Plugins nutzt und auch die Entwickler kein Interesse haben, das CrystalHD Modul zu unterstützen. Sehr Schade.  :-(

Achja, Danke an Jarod Wilson für den Treiber bzw. das GIT Repo.

Nach jedem Kernelupdate müsst ihr übrigens das Kernelmodul neu installieren.

Das wars mit meinem ersten Beitrag zum WeTab, ich denke es folgen vllt. noch weitere.

Pearl Display als Dockstar-gesteuerter Bilderrahmen

Bild der Dockstar mit laufender Slideshow

Nachdem wir nun lcd4linux das Image Widget ja erfolgreich eingetrichtert haben und mein zweites Display auch was zu tun möchte, will ich daraus eine kleine Slideshow machen. Natürlich kann der kleine DPF das schon, aber er hängt eh am USB, dann kann die Dockstar das auch gleich steuern.

Erstmal die Dokumentation des Widget_Image von lcd4linux hier lesen. Um das Ziel zu erreichen gibt es prinzipiell 2 Wege.

Voraussetzung ist immer ein Ordner voller 320×240(!) PNG(!!) Bilder.

Weg 1: Das Image Widget von lcd4linux kann auf Dateiänderungen reagieren, wir erzeugen nun ein Skript (Python?) und dieses Skript sucht zufällig eine Datei aus dem Bilderordner und kopiert sie immer an die gleiche Stelle. Diese Datei, die immer wieder überschrieben werden soll, nehmen wir als Bild in unserer lcd4linux.conf und setzen reload=1 und update=5000 (alle 5 sek. wird also geprüft ob sich was geändert hat). Danach erzeugen wir einen Cronjob, der das Skript alle 30 Sekunden ausführt und damit die Bilddatei alle 30 Sekunden aktualisiert mit einem zufälligen Bild.

Weg 2: Wir wählen die Python Funktion von lcd4linux, was für uns 2 Nachteile bedeutet erstmal: Erstens müssen wir uns im PYTHONPATH rumschlagen oder das Skript in einen Ordner, in dem Python es direkt findet, kopieren. Zweitens: Wir müssen lcd4linux mit dem python flag neu kompilieren. Dafür sparen wir uns aber cron und hässliches kopieren alle 30 Sekunden.

Was nehmen wir nur? Natürlich Weg 2.

Ich gehe davon aus, dass ihr Python usw. alles installiert habt. Wenn nicht, googelt einfach danach.

Schritt 1) Kompilieren lcd4linux

Zuerst installieren wir libpython2.6:

sudo apt-get install libpython2.6

Nun kompilieren wir lcd4linux genau gleich wie in meinem anderen Artikel, nur bauen wir die configure Zeile in build-dpf-lcd4linux.sh wie folgt um:

./configure --with-drivers='DPF' --with-plugins='all,!dbus,!mpris_dbus' --with-python

Danach ganz normal wie dort geschrieben weiter machen.

Ich hab hier (md5:771b71903f6b67d07d258b87c2e579cf) auch mein python-enabled lcd4linux hochgeladen, falls jemand nicht so auf kompilieren steht.

Jetzt wählen wir 2 Ordner, einer mit Bildern und einer, in dem das Skript liegt. Wir nehmen für die Bilder /home/user/pics und fürs Skript /home/user.

Danach öffnen wir als Root die Datei /etc/profile und fügen ganz unten folgende Zeilen hinzu:

PYTHONPATH="/home/user/"
export PYTHONPATH

Das ist ganz wichtig, damit root unseren Home Ordner auch für Pythonskripte durchsucht. Damit das klappt, rebooten wir nun einmal die Dockstar.

Jetzt erstellen wir die Datei /home/user/slideshow.py und kopieren folgendes hinein:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import os
import random

img_folder="/home/user/pics" # Anpassen, Ordner mit Pics darin
                             # AM ENDE KEIN /
walker = os.walk(img_folder,True,None)
pics = [] # leer lassen

def give_random_pic(self):
        for i in walker:
                if len(i[2]) > 0:
                        for j in i[2]:
                                if j.split(".")[-1] == "png": # Pruefe ob die Endung .png ist
                                        pics.append(i[0]+"/"+j)
        rn = random.randrange(0,len(pics),1)
        return pics[rn]

Danach noch folgende Befehle ausführen:

sudo chown root:root slideshow.py
sudo chmod 700 slideshow.py

Was fehlt ist die passende /etc/lcd4linux.conf:

Display dpf {
    Driver     'DPF'
    Port       'usb0'
    Font       '6x8'
    Foreground 'ffffff'
    Background '000000'
    Basecolor  '000066'
}
Widget FIRST {
    class 'Text'
    expression 'www.Geekparadise.de'
    width 54
    align 'L'
    update 0
    Background 'ffffff'
    Foreground  '000000'
}

Widget IMAGE {
    class    'Image'
    file     python::exec('slideshow', 'give_random_pic', '')
    update   30000
    reload   1
    visible  1
    inverted 0
}

Display 'DPF'

Layout Dockstar{
    Row01.Col01  'FIRST'

    Layer 2 {
	X1.Y1 'IMAGE'
    }

}

Layout 'Dockstar'

Einmal lcd4linux neugestartet und schwupps ist euere Slideshow fertig. Toll oder?

Achja, das python Skript prüft nur ziemlich rudimentär ob es png Dateien sind .. selber schuld wer jpegs mit Endung .png reinkopiert…

Am Schluss – wie immer – :
Warnung: Dabei kann man seinen digitalen Bilderrahmen durchaus unbrauchbar machen. Ich übernehme keine Verantwortung für gebrickte Digitale Bilderrahmen oder sonstige Schäden die durch diese Anleitung verursacht werden. Jeder muss selbst wissen was er tut.

Python: UTF-8 zu Latin-1 bzw. ISO 8859-1 kodieren

Wenn man in Python einen (UTF-8) String in Latin-1 bzw. ISO 8859-1 kodieren will, hat man öfters das Problem, wenn man nur

blubb.encode('latin-1')

nutzt (wobei blubb ein String ist oder sowas), das öfters mal folgender Fehler kommt:

UnicodeError: ASCII encoding error: ordinal not in range(128)

Das lässt sich lösen, in dem man ihn vorher in die interne Unicode Darstellung von Python konvertiert:

unicode(blubb, 'utf-8').encode('latin-1')

Schon kommt kein Fehler mehr ;)

Pearl Statusdisplay Akku raus?

Falls jemand vor hat, die Pearl AX206er Displays in ihrem ernsthaften Zweck zu nutzen, kann ich demjenigen nur dringend abraten, welche zu ordern. Bei all meinen Digitalen Bilderrahmen waren die Akkus schon bei Ankunft am Ende und wurden auch nach 2 Tagen am (USB-) Strom nicht besser, beide so um die 2-2.5 volt herum.

Da ich Chinaakkus nicht traue (v.a. nicht im Dauerbetrieb), hab ich ihn kurzer Hand ausgelötet, das geht recht einfach, die 4 Chinaschrauben (… ihr werdet bei der Schraubenziehersuche merken warum ich sie so nenne…) lösen, Deckel abheben und die beiden im Bild markierten Kabel ablöten oder nah an der Lötstelle abzwacken:

Bild der Rückseite

Klick für größere Ansicht

Der Akk ist auch mit doopelseitigem Klebeband noch etwas fixiert, aber das lässt sich leicht lösen. Ich würd das Display nicht großartig weiter aus dem Plastikgehäuse heben, sonst müsst ihr nachher nur den Staub entfernen, wenn welcher drauf kommt.

Bild des ausgelöteten Akkus

Klick für Großansicht

Akku ist übrigens ein HBK, 200 mAh, Modell 042030, Normal 3.7 V, Max. 4.2 V

Ihr verliert aber einige Funktionen dadurch: z.B. merkt er sich nicht mehr die Uhrzeit und nicht mehr die Displayhelligkeit (immer wieder auf 10 nachdem man es abgesteckt hat.). Damit kann man denke ich Leben, im Gegenzug gewinnt man ja mehr Sicherheit. Vllt. bekommt Hackfin ja auch noch die Helligkeitssteuerung via lcd4linux hin, dann ist das eh kein großer Nachteil mehr.

Warnung: Dabei kann man seinen digitalen Bilderrahmen durchaus unbrauchbar machen. Ich übernehme keine Verantwortung für gebrickte Digitale Bilderrahmen oder sonstige Schäden die durch diese Anleitung verursacht werden. Jeder muss selbst wissen was er tut

XFCE & Thunar gegen Luks & mount.crypt

Hi,

wer ebenfalls Probleme beim Mounten seiner Luks/Cryptsetup Laufwerke mit mount.crypt in einer XFCE Umgebung hat und den Fehler “Sie sind nicht dazu berechtigt Datenträger … einzubinden” bzw. “Der Datenträger … konnte nicht eingebunden werden” hat, weiß das man den Fehler fast nicht weg bekommt mit den gewohnten Mitteln. Normalerweise würde man erwarten, das Thunar die UDISKS_PRESENTATION_HIDE Option respektiert via Udev Regel .. nö.

Fehlermeldung in Thunar

Ordnername geschwärzt

Einfacher Trick: Thunar öffnen, Bearbeiten->Einstellungen->Fortgeschritten-> Aufs unterstrichene “Verwaltung” klicken und die Option “Hotplug-Wechsellaufwerke automatisch einhängen” deaktivieren. USB Sticks und so werden trotzdem gemountet.

Damit ist das Problem behoben ;)

Nautilus macht solche Spaken übrigens nicht und respektiert Udev Regeln gescheit.

Netio auf der Dockstar

Wer den Netzwerkdurchsatz seiner Dockstar mal austesten möchte, kann dies mit Netio tun.

Netio von ARS Computer gibt es hier. Leider werden nur Binaries für Windows,Mac,Linux x86-32 und x86-64 bereit gestellt und keine für arm.

Also kompilieren wir es auf der Dockstar, was auch ohne Probleme funktioniert.

wget http://www.ars.de/ars/ars.nsf/f24a6a0b94c22d82862566960071bf5a/aa577bc4be573b05c125706d004c75b5/\$FILE/netio131.zip
unzip netio131.zip
make linux

Fertig. Falls euch irgendwelche Abhängigkeiten oder unzip fehlen, einfach danach googeln.
Unter umständen müsst ihr noch ein chmod +x netio ausführen.

Jetzt können wir zu einem Netio Server connecten mit einem der folgenden Befehle (je nachdem ob udp oder tcp):

./netio -t

oder

./netio -u

oder einen Netio Server aufmachen (immer udp+tcp) mit

./netio -s

Man sieht, dass die Dockstar das volle Gigabit Lan nicht ausschöpfen kann, hier als Beispiel die Dockstar verbunden mit dem Netio Server auf meinem Home PC via tcp:

Packet size  1k bytes:  29.41 MByte/s Tx,  46.81 MByte/s Rx.
Packet size  2k bytes:  33.56 MByte/s Tx,  52.61 MByte/s Rx.
Packet size  4k bytes:  44.98 MByte/s Tx,  56.19 MByte/s Rx.
Packet size  8k bytes:  57.70 MByte/s Tx,  60.70 MByte/s Rx.
Packet size 16k bytes:  66.33 MByte/s Tx,  63.96 MByte/s Rx.
Packet size 32k bytes:  70.75 MByte/s Tx,  67.40 MByte/s Rx.
Done.

Der Server zeigt folgendes an:

Receiving from client, packet size 1k … 29.40 MByte/s
Sending to client, packet size 1k … 46.83 MByte/s
Receiving from client, packet size 2k … 33.55 MByte/s
Sending to client, packet size 2k … 52.65 MByte/s
Receiving from client, packet size 4k … 44.97 MByte/s
Sending to client, packet size 4k … 56.58 MByte/s
Receiving from client, packet size 8k … 57.68 MByte/s
Sending to client, packet size 8k … 60.73 MByte/s
Receiving from client, packet size 16k … 66.32 MByte/s
Sending to client, packet size 16k … 63.98 MByte/s
Receiving from client, packet size 32k … 70.74 MByte/s
Sending to client, packet size 32k … 67.42 MByte/s
Done.

In die andere Richtung sieht es genau gleich aus, es macht keinen Unterschied ob die Dockstar Server oder Client ist.

Digitaler Bilderrahmen von Pearl als Statusdisplay für Dockstar

Jeder der eine Dockstar hat, kennt das Problem, es fehlt ein kleines Statusdisplay oder sowas zum erschwinglichen Preis.  Nun gibt es im <10 € Bereich so genannte “Digitale Bilderrahmen” bzw. DPFs (Digital Photo Frame), die eigentlich optimal für so etwas sind. Ich nenne die Digitalen Bilderrahmen ab jetzt nur noch DPF, nicht wundern.

Es begann mit der Möglichkeit DPFs mit dem st2205 Chip zu “hacken” und sie als Display für lcd4linux zu nutzen.  Problematisch: Es war schwer vorherzusagen, welche DPFs diesen Chip haben und welche nicht. Später entwickelte Martin Strubl von Section5 eine Methode (hier) DPFs mit AppoTech’s AX206 Chip als Display für lcd4linux zu nutzen, allerdings ist der “Hack” noch etwas im Anfangsstadium und nicht soweit fortgeschritten wie für st2205 Displays, dort gibt es bereits Firmwares usw. Das ist aber anscheinend auch für den AX206 in Zukunft geplant. Vorteil beim AX206 ist, dass wir dank einigen Usern (hier und hier) wissen, wo es genau solche DPFs mit 2.4″ Display gibt. Aussehen tut das ganze dann so:

Bild des Pearl Bilderrahmens

Klick für größere Ansicht

Es ist übrigens besser ablesbar als man hier erkennt, es ist doch nicht so einfach das richtig abzufotografieren. In der Realität ist das alles scharf und den schwarzen Text auf weißem Hintergrund kann man auch lesen.

Es gibt nun gefüllte 100 Puzzleteile im Netz, wie man das Teil vollständig zum Laufen bekommt. Ich werd das nun versuchen mal zusammengefasst zu schildern. Vorab schon einmal danke an alle die das möglich gemacht haben.

Voraussetzung: In meinem Fall eine Dockstar mit Debian Squeeze, prinzipiell sollte es aber auch ein PC mit beliebiger Distribution tun. (Die Paketnamen sind dann eben anders.)

Ich selbst nutze sudo, wer das nicht tut, muss sudo eben weglassen und die Befehle als root ausführen.

Warnung: Dabei kann man seinen digitalen Bilderrahmen durchaus unbrauchbar machen. Ich übernehme keine Verantwortung für gebrickte Digitale Bilderrahmen oder sonstige Schäden die durch diese Anleitung verursacht werden. Jeder muss selbst wissen was er tut.

1) Kompilieren von dpfhack und lcd4linux

Für den ersten Schritt können wir uns eigentlich an die Anleitung von celemine1Gig halten, die er hier gepostet hat. Allerdings hat er 1-2 kleine Fehler gemacht, die wir geschickt umschiffen:
Erstmal installieren wir alle Abhängigkeiten:

sudo apt-get install libtool automake autoconf zlib1g-dev libssl-dev python-dev libc6 libusb-dev libibus-dev subversion libgd2-noxpm-dev libgd2-noxpm

Was fällt auf? Im Gegensatz zu celemine haben wir libgd2-noxpm dabei, damit hat man nachher auch das Image-Widget in lcd4linux, was ansonsten fehlen würde. (erwähnt wurde das hier von hackfin.)

Danach brauchen wir noch ein neueres sdcc für squeeze, was wir runterladen und ebenfalls installieren:

wget ftp://ftp.debian.org/debian/pool/main/s/sdcc/sdcc-libraries_2.9.0-5_all.deb
wget ftp://ftp.debian.org/debian/pool/main/s/sdcc/sdcc_2.9.0-5_armel.deb
dpkg -i sdcc-libraries_2.9.0-5_all.deb
dpkg -i sdcc_2.9.0-5_armel.deb

Danach laden wir dpfhack-0.1alpha.tgz, entpacken es und kompilieren es:

 

wget http://tech.section5.ch/files/dpfhack-0.1alpha.tgz
tar -xvzf dpfhack-0.1alpha.tgz
cd dpf/src
make

 

Dies dürfte nun erfolgreich kompiliert sein, achtet auf Fehlermeldungen. Nun kommt lcd4linux dran:

cd ..
wget http://tech.section5.ch/files/dpf-lcd4linux.tgz
tar -xvzf dpf-lcd4linux.tgz

Nicht wundern, er entpackt es ins gleiche Verzeichnis wie schon den dpfhack. An diesem Punkt müssen wir jetzt die Datei build-dpf-lcd4linux.sh etwas anpassen, und zwar anders als celemin das in seinem Beitrag tat. Wir ändern die Zeile

./configure --with-drivers=DPF

in

./configure --with-drivers='DPF' --with-plugins='all,!dbus,!mpris_dbus'

Wichtig sind die einfachen Anführungszeichen um DPF. Bei dem “–plugin”-Teil lassen wir bewusst dbus Sachen weg, sonst motzt er ständig wegen dem fehlenden DBUS auf dem Debian der Dockstar. Wer DBUS installiert hat oder DBUS Plugins später nutzen will, sollte !dbus und !mpris_dbus aus der Zeile entfernen. Sollte es nicht gehen, versucht –with-drivers=ALL. Es geht aber definitiv so wie oben beschrieben, hab es selbst probiert.

Nun konfigurieren & kompilieren wir lcd4linux mit der AX206 Library:

./build-dpf-lcd4linux.sh ../src/dpflib/

(Wichtig sind die 2 Punkte vor /src/dpflib/, warum erklärt celemin hier.)

Beim Download des Quellcodes aus dem Repository kommt anfangs eine Zertifaktsfrage:

– Das Zertifikat ist nicht von einer vertrauenswürdigen Instanz ausgestellt
Überprüfen Sie den Fingerabdruck, um das Zertifikat zu validieren!
Zertifikats-Informationen:
– Hostname: ssl.bulix.org
usw.

Einfach mit “t” temporär akzeptieren. (Es wird übrigen Revision 1142 ausgecheckt. Ich hab es kurz mit der neusten Revison 1143 getestet, der Patch dürfte dort auch klappen – bringt aber keine Vorteile.)

Danach können wir es einfach mit

cd lcd4linux
sudo make install

bzw. mit

cd lcd4linux
sudo checkinstall

installieren. Ich selber empfehle checkinstall, weil man später das Paket leicht wieder löschen kann und man die Paketverwaltung nicht umgeht. Allerdings mag checkinstall die Versionsnummer nicht, welche man auf 0.11.0-SVN ändern sollte. (oder irgendwas beliebiges).

Man kann sich den gesamten Schritt 1 sparen, wenn man mir vertraut und mein fertiges Debian Paket hier (md5: 23dc6b5c4cc44390e9364970be97cf03) herunterlädt. Das muss man dann nur noch mit dpkg -i <name des pakets> installieren. Von den Abhängigkeiten muss man nur libgd2-noxpm installieren, alle anderen sind nur fürs kompilieren nötig. (Kann sein dass noch irgendwas dazu kommt, was ich eh schon drauf hatte.). Man kann so auch das Paket auf einer zweiten Dockstar kompilieren und dann das Paket von checkinstall übertragen. (so hab ich es gemacht.). ABER: Man braucht für Schritt 2 Teile des dpfhack und muss diesen demnach sowieso kompilieren und brauch auch die anderen Abhängigkeiten u.U.. Es spart einem also nur Zeit, wenn der DPF bereits gehackt ist.

Als Backup hab ich die beiden Quelltextarchive dpfhack-0.1alpha.tgz (md5: 415398689d2ea77e83a79c513d44da82) und dpf-lcd4linux.tgz (md5: 3cccca2797ebb85459dc272a8b9e9b67) auch nochmal als Download hochgeladen.

2) “Hacken” des DPF

Wir haben nun schon einiges in Schritt 1 vorbereitet, jetzt müssen wir den DPF “hacken”.  Dazu gehen wir in den dpf/src Ordner. Der Befehl dazu, sofern ihr noch im lcd4linux Ordner seid, lautet:

cd ../src

Nun schalten wir den DPF an (etwas länger Menü drücken) und stecken ihn an, gehen ins Menü des DPF und aktivieren “mit PC verbinden” und schauen uns an, was dmesg nun sagt: (es sollte bei euch in etwa gleich aussehen)

[ 6803.710565] usb 1-1.3: new full speed USB device using orion-ehci and address 4
[ 6803.875039] usb 1-1.3: New USB device found, idVendor=1908, idProduct=0102
[ 6803.881970] usb 1-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[ 6803.889318] usb 1-1.3: Product: Digital Photo Frame
[ 6803.894253] usb 1-1.3: Manufacturer: BUILDWIN
[ 6803.901500] usb 1-1.3: configuration #1 chosen from 1 choice
[ 6803.916037] scsi1 : SCSI emulation for USB Mass Storage devices
[ 6803.925274] usb-storage: device found at 4
[ 6803.925285] usb-storage: waiting for device to settle before scanning
[ 6808.921809] usb-storage: device scan complete
[ 6808.927740] scsi 1:0:0:0: CD-ROM            buildwin  Photo Frame     1.01 PQ: 0 ANSI: 2
[ 6808.982804] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[ 6808.989629] Uniform CD-ROM driver Revision: 3.20
[ 6808.996006] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 6809.028232] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6809.036215] sr 1:0:0:0: Attached scsi generic sg1 type 5

Danach starten wir den Hack(komischerweise meldet sich mein DPF als sg0 und sg1 .. achtet bitte auf eure dmesg Ausgabe. Das Skript warnt euch aber, falls ihr eure Festplatte schrotten wollt, kann eigentlich nicht viel passieren, zumal solche Geräte sda,sdb usw. heißen):

sudo python hackit.py /dev/sg1

Das Skript erklärt am Schluss auch gleich, wie wir den DPF ab jetzt in den Developer Mode bekommen:

Zum Developer Mode: Press and hold MENU while USB is plugged in.If successful, you will get the ‘USB connect’ message and the devicewill appear as non-USB storage device
To put the device back into (almost) original state workingas USB storage, press the RESET button.

Also machen wir das: Kurz ab und anstecken und danach Menü gedrückt halten ( 2-3 Sek.) bis USB verbunden dran steht. Danach sagt dmesg:

[ 7027.710565] usb 1-1.3: new full speed USB device using orion-ehci and address 5
[ 7027.875035] usb 1-1.3: New USB device found, idVendor=1908, idProduct=0102
[ 7027.881966] usb 1-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 7027.889314] usb 1-1.3: Product: USB-Display
[ 7027.893551] usb 1-1.3: Manufacturer: hackfin
[ 7027.897843] usb 1-1.3: SerialNumber: 0000
[ 7027.904154] usb 1-1.3: configuration #1 chosen from 1 choice

Das sollte nun bei euch auch so aussehen.

Nun brauchen wir noch eine /etc/lcd4linux.conf. Wie man die genau erstellt und was man damit für Möglichkeiten hat, kann jeder selber ergoogeln. Zum Testen könnt ihr einfach folgendes nehmen.

Display dpf {
    Driver     'DPF'
    Port       'usb0'
    Font       '6x8'
    Foreground 'ffffff'
    Background '000000'
    Basecolor  '000066'
}
Widget FIRST {
    class 'Text'
    expression 'www.Geekparadise.de'
    width 54
    align 'L'
    update 5000
    Background 'ffffff'
    Foreground  '000000'
}
Display 'DPF'

Layout Dockstar{
    Row01.Col01  'FIRST'
}

Layout 'Dockstar'

Beispielsweise könnt ihr das mit Nano in die Datei lcd4linux.conf reineditieren.

sudo nano /etc/lcd4linux.conf

Falls ihr ein Bild anzeigen wollt, sieht das Widget dafür so aus (es gehen nur .png):

Widget IMAGE {
    class    'Image'
    file     '/pfad/zur/bla.png'
    update   10000
    reload   1
    visible  1
    inverted 0
}

Neugestartet wird lcd4linux mit

sudo killall lcd4linux && sleep 1 && sudo lcd4linux

Ebenso muss die Datei lcd4linux dem ausführendem Besitzer (hier root, anders ging es nicht) gehören und die Rechte 600 besitzen. ( sudo chown root:root /etc/lcd4linux.conf und sudo chmod 700 /etc/lcd4linux.conf).

Will man eine andere Datei nutzen, so muss man -f <dateiname> anhängen.

Die Ausgabe von lcd4linux sieht man, wenn man es nicht als Daemon startet, also mit -F.

Einen Tipp hab ich noch: Sollte irgendwo ein Fehler in der Konfig sein oder irgendwas nicht evaluierbar sein, kommt nicht immer ein Fehler, sondern lcd4linux verursacht dann manchmal plötzlich eine sehr hohe Systemauslastung. Normal sollte diese < 2% sein.

Weitere Informationen gibt es hier und am Ende des Artikel, dort verlinke ich auch ein paar Beispielkonfigurationen einiger Dockstaruser, welche mir so über den Weg gelaufen sind während dem Suchen.

3) Udev Regel / rc.local

Schritt 3 ist eher der Bequemlichkeit geschuldet, weil es nervt, lcd4linux immer von Hand zu starten. Ausserdem bleibt es hängen, sobald man dem DPF unbedacht absteckt. Also schreiben wir eine Udev Regel, wie das genau geht findet sich hier und hier.

Wir benötigen 2 Regeln, einmal fürs “Abstecken” und einmal fürs “Anstecken”. Beginnen wir mit der “Ansteckregel”, dafür 2 Ausgaben:

dmesg:

[6493023.221634] usb 1-1.3: USB disconnect, address 34
[6493100.511631] usb 1-1.3: new full speed USB device using orion-ehci and address 35
[6493100.676135] usb 1-1.3: New USB device found, idVendor=1908, idProduct=0102
[6493100.683461] usb 1-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[6493100.691430] usb 1-1.3: Product: USB-Display
[6493100.696177] usb 1-1.3: Manufacturer: hackfin
[6493100.701038] usb 1-1.3: SerialNumber: 0000
[6493100.707923] usb 1-1.3: configuration #1 chosen from 1 choice

lsusb -v:

Bus 001 Device 035: ID 1908:0102
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0         8
  idVendor           0x1908
  idProduct          0x0102
  bcdDevice            2.00
  iManufacturer           2 hackfin
  iProduct                3 USB-Display
  iSerial                 1 0000
  bNumConfigurations      1

Nun erzeugen wir nun die Datei /etc/udev/rules.d/70-dpf.rules und fügen folgende Zeile hinein:

BUS=="usb", ACTION=="add",SYSFS{idProduct}=="0102", SYSFS{idVendor}=="1908", RUN+="/usr/local/bin/lcd4linux"

Damit wird automatisch lcd4linux gestartet wenn man den DPF im Developer Mode dran hängt. Die beiden ids sollten bei euch gleich sein, wenn ihr den Pearl DPF habt. Schaut aber zur Sicherheit nach!

Achja, damit die Regel geht, müsst ihr udev neustarten mit sudo /etc/init.d/udev restart oder sudo /etc/init.d/udev reload.

Für die “Absteckregel” müssen wir andere Tools zu Rate ziehen, da das obige beim “remove” nicht geht, bzw. die SYSFS Informationen schlicht nicht mehr verfügbar sind. Daher schauen wir uns an was udev so treibt mit folgendem Befehl:

sudo udevadm monitor --property

Wenn man den DPF absteckt, sieht das so aus (ich hab das gekürzt):

UDEV  [1302474093.969410] remove   /devices/platform/orion-ehci.0/usb1/1-1/1-1.3/1-1.3.1 (usb)
UDEV_LOG=3
ACTION=remove
[...]
ID_VENDOR=hackfin
ID_VENDOR_ENC=hackfin
ID_VENDOR_ID=1908
ID_MODEL=USB-Display
ID_MODEL_ENC=USB-Display
ID_MODEL_ID=0102
ID_REVISION=0200
ID_SERIAL=hackfin_USB-Display_0000
[...]

Daraus ergibt sich die zweite Regel welche wir ebensfalls zur /etc/udev/rules.d/70-dpf.rules hinzufügen. Diese Datei sollte dann so aussehen (killall sollte installiert sein, keine Ahnung ob Debian das standardmäßig hat):

BUS=="usb", ACTION=="add",SYSFS{idProduct}=="0102", SYSFS{idVendor}=="1908", RUN+="/usr/local/bin/lcd4linux"
SUBSYSTEM=="usb", ACTION=="remove", ENV{ID_MODEL_ID}=="0102", ENV{ID_VENDOR_ID}=="1908", RUN+="/usr/bin/killall lcd4linux"

Wem udev zu kompliziert ist, hat wenigstens die Möglichkeit beim Starten der Dockstar das Display aktivieren zu lassen, in dem er die Zeile “/usr/local/bin/lcd4linux” zur /etc/rc.local hinzufügt. (Eine Zeile vor “exit 0”.) Dann muss aber beim Booten der DPF bereits im Developer Modus an der Dockstar hängen. (oder später angesteckt und von hand lcd4linux gestartet werden.)

4) Wo gibts das Teil? Costa Quanta?

Es gibt mehrere Quellen und auch mehrere AX206 DPF, aktuell bevorzuge ich eigentlich Pearl.de. Dort gibt es den DPF, den ihr oben im Bild seht, für 2,90 € (HPM-1184-904) und für 9,90 € (PX-1184-904). Die sind beide gleich, von ersterem darf allerdings pro Bestellung nur einer dazu bestellt werden. Gegen mehrere Bestellungen spricht natürlich nichts… ;-)

Dazu kommen 4,90 € (LSV) bzw. 6,90 € (NN) Porto und 2,50 € Mindermengenzuschlag, falls ihr unter 17,50 € seid. Zusätzlich könnt ihr euch noch einen Aktionsartikel mit in den Warenkorb legen, ich empfehle den 8 GB Verbatim USB Stick für 2,90 € (GRA-8294-935) zu nehmen oder die Osram LED Taschenlampe für 0 € (GRA-16629-904), die den Vorteil hat, dass der Mindermengenzuschlag entfällt. Warum weiß ich auch nicht, Bug im Shop denke ich, wird vermutlich bald gefixt. Für andere Gratisartikel einfach mal Google anschmeißen.

Edit: Ich muss sagen, die Taschenlampe lohnt sich echt. Unbedingt nehmen! Was ich schade finde: Man bezahlt 4,90 € Porto + Mindermengenzuschlag und Pearl schickt einem das Zeug mit einer Warensendung für 1,65 €(Sowohl der Preis, als auch “Warensendung” stehen auf dem Paketaufkleber).

Weitere, unbestätigte Quellen sind: (unbestätigt weil ich sie nicht selbst probiert hab…)

Dealextreme 2.4″ DPF – Dealextreme 2.4″ DPF #2 als HerzDealextreme 1.5″Dealextreme 1.5″ #2Ebay #1 – Ebay #2

Im Endeffekt ist Pearl am günstigsten für 10,30 € mit der LED Taschenlampe oder 13 € mit dem 8 GB USB Stick.

5) Links zum Thema:

Wikiartikel auf picframe.spritesserver.nl (da er immer mal wieder Probleme hat, hier der Google Cache Link)
Blog von section5
hkramski’s buildzeile
hkramski’s Erklärung + Links
hackfin’s Erklärung wie man Image Widget Support bekommt
– celemine1Gig Tutorial
weiteres Post von celemine1Gig
weiteres Post von celemine1Gig #2
– LCD4LINUX WikiHauptseite Manual
Bild des Pearl DPF
– Bild des Pearl DPF nackt #1 #2 #3 #4
Bild des Pearl DPF ohne den durchsichtigen Rahmen
Bild #1 und die Beispielkonfig daraus hier. Quelle hier.
– Bild #2,#3 und die Beispielkonfig daraus gibts hier. Quelle hier.
Beispielkonfig

6) Ausblick

Man liest öfters dass es bald ebenfalls eine “custom”-FW für die AX206 DPFs geben soll und auch die Hintergrundbeleuchtung soll bald steuerbar sein via lcd4linux. Ich denke und hoffe dass sich da noch einiges tun wird, obwohl es, bis auf die fehlende Steuerung der Hintergrundbeleuchtung, echt gut klappt. Ausserdem hoffe ich, dass man auch bald direkt in den Developermodus kommen kann sobald man den DPF ansteckt – “Menütaste gedrückt halten” nervt doch etwas. Alternativ wäre es gut, wenn man die Hintergrundbeleuchtung einfach deaktivieren könnte.

Um die Stecker und Nerven zu schonen nutz ich aktuell einen USB Hub mit Ausschalter von DealExtreme. Somit muss man nur noch Schalter umlegen & Menü drücken ;-)

7) Nachtrag

– Der Standfuß geht mega schnell kaputt, beim 3. oder 4. mal ab-klipsen bricht er. Vorsicht also!

– Wer vor hat, das Display mit Akku zu betreiben .. lasst es. Alle meine Displays kamen mit praktisch schon total plattem Akku an.  Da geht nicht mehr viel, selbst wenn es 2 Tage am USB hing, hält der Akku nur kurz.

– Wer den Akku (hauptsächlich aus mangelndem Vertrauen zu China-Akus) ausbauen will, findet hier meine Anleitung dazu.

– Wer lcd4linux mit -q startet, erspart sich die Werbung beim Starten/Beenden von lcd4linux auf dem Display. Geht natürlich auch mit Udev.

– Wer -q benutzt, wird (sofern er kein Image Widget als Hintergrund nutzt) einen Bug bemerken: lcd4linux ignoriert

Background '...'
Basecolor  '...'

Und man hat auch nach dem Anstecken noch das “USB verbunden” mit dem weißen Hintergrund dastehen. Ansonsten wenn man lcd4linux neustartet bleibt es einfach blau als Hintergrund.
Lösung: -q weglassen oder Hintergrundbild (schwarz z.B.)

– falls jemand folenden Fehler erhielt:

calling SCSI ioctl(): Bad file descriptor
SCSI inquiry failed
Traceback (most recent call last):
  File "hackit.py", line 134, in 
    d = dpf.open(sys.argv[1])
SystemError: Failed to open port:
File open error

Das war meine Schuld (mehr oder weniger) .. ich hab oben vergessen zu schreiben, das man natürlich im Menü des DPF die USB Verbindung aktivieren muss. I am sorry for that! -> korrigiert.

– Es gibt eine neuere Version des Dpfhacks hier. Vorsicht: Noch im experimentellen Stadium!

Bastel aus hwluxx-forum hat etwas interessantes entdeckt:
Wenn man den DPF ansteckt und 5-10 Minuten wartet, geht er automatisch in den “Hackfin” Modus. Voraussetzung ist das aktivieren der Diashow, es klappt aber definitiv in den Standardeinstellungen (ohne AKKU also). Krasse Sache, Danke Bastel!

Linux: Großer Geschwindigkeitsvergleich EncFS/eCryptfs/TrueCrypt/Luks

Bild der Verschlüsselungen

Neulich wollte ich es endlich mal wissen, wie groß sind denn die Performanceunterschiede zwischen EncFS, eCryptfs, Truecrypt und Luks/Cryptsetup?

Daher hab ich hier mal versucht, einen möglichst praxisnahen Performancevergleich zu machen:

Das wichtigste am Anfang:

  • OS: Ubuntu 10.10 x64 2.6.35-28-generic
  • Hardware: AMD Phenim II X4 965 Black Edition (4 Kerne, Standardtakt), 8 GB DDR3 RAM.
  • Alle verschlüsselten Ordner/Container lagen auf einer Vertex 2 SSD(32nm), auf der auch Ubuntu 10.10 lag.
  • Passphrase war übrigens überall gleich und immer “abcdefg”
  • Verschlüsselung war überall (so gut es eben ging gleiche Bedingungen zu schaffen) AES-128

Folgendermaßen bin ich vorgegangen:

  • Raumlaufwerk erzeugt mit sudo mount -t tmpfs none /pfad/zum/einhängepunkt (siehe hier)
  • Gemessen wurde mit vorangestelltem time (Nautilus: Stoppuhr). Die Angaben sind immer entsprechend der Ausgabe von time, also sprich Realzeit/User CPU-Zeit/System CPU-Zeit untereinander. (Ausnahme: Zusatzrunde 1 &2)
    Beispiel: 

    Truecrypt
    1. Rundereal
    user
    system
  • Es wurden Durchgänge mit cp und rsync und am Schluss Nautilus gemacht -> Damit die Variable “es liegt am Kopieprogramm” ausgeschlossen wird. Ab Testreihe 2 kein rsync mehr!
  • Testreihe 1: Es wurden je 2 Schreibvorgänge (cp/rsnyc) mit dem immer gleichen Testfile gemacht in beide Richtungen (crypted -> Ram und Ram -> crypted, also 16 Vorgänge).
  • Ab Testreihe 2: Es wurden je 1 Schreibvorgänge mit den immer gleichen Testfiles gemacht in beide Richtungen (crypted -> Ram und Ram -> crypted, also 8 Vorgänge).
  • Reihenfolge innerhalb einer Testreihe: CP -> LUKS,EcryptFS,Truecrypt,EncFS danach Rsync -> LUKS,EcryptFS,Truecrypt,EncFS
  • Alle 4 Container/Ordner sind immer gemountet während des ganzen Vorgangs. Es wurde nebenher nichts anderes am PC gemacht!
  • Es wurden 3 verschiedene Testreihen mit verschiedenen Dateien und eine Zusatzrunde mit Nautilus (mit etwas anderem Ablauf s.u.) gemacht.

Die Prozessorauslastung wollte ich auch messen, es war allerdings schlicht zu kompliziert, da der Prozessor ja hoch und runter taktet und z.B. bei LUKS es abwechselnd immer eine hohe Auslastung und dann wieder gar keine Auslastung gab und bei Ecryptfs wiederum konstante Auslastung eines Kerns. Daher hab ich den Teil weg gelassen.

Falls ich Worte durcheinander werfe,  ich benutze folgende Worte jeweils synonym:

Lesen = von dem jeweiligen verschlüsselten Medium lesen und auf das Ramlaufwerk kopieren = Ram -> Crypted

Schreiben = vom Ramlaufwerk auf das jeweilige verschlüsselte Medium kopieren = Crypted -> Ram

Konfiguration der einzelnen Verschlüsselungen:

  • LUKS/Cryptsetup:
    • 8 GB großes Container File
    • Erstellung:
      dd if=/dev/zero of=container_file bs=1M count=8000 
      sudo losetup -f 
      sudo losetup /dev/loop0 container_file 
      sudo cryptsetup -c aes-xts-plain -y -s 256 luksFormat /dev/loop0
    • Darauf dann ein ext4 Filesystem erstellt
    • Cryptsetup Version 1.1.2
    • Genaueres Anleitung siehe hier.
    • AES-XTS-Plain 256 =  AES128, siehe hier.
  • EcryptFS:
    • Ordner “Test” erstellt und mit eCryptfs verschlüsselt
    • mkdir Testsudo
      mount -t ecryptfs ./Test ./Test
    • Cipher = aes
    • Blocksize = 16 (=AES 128)
    • Enable plaintext passthrough = y
    • Enable filename encryption = y
    • FNEK wurde der vorgeschlagene genommen
    • Version 83-0ubuntu3
    • Siehe hier und hier.
  • Truecrypt(TC):
    • Container -> container_file2.tc
    • Verschlüsselungsalgorithmus -> AES
    • Hash Algorithmus -> RIPEMD-160
    • Don’t use keyfiles (standardmäßig nicht angehakt)
    • Größe des Containers 8 GB
    • “i will store files larger than 4 GB on the volume”
    • Linux Ext4
    • “I will mount the volume only on Linux” = TC nutzt die Kernel Crypto Mudole
    • Version 7.0a
  • EncFS:
    • Ordner “Test2” und “.Test2”, wobei in letzterem die verschlüsselten Dateien liegen sollen.
    • encfs ~/.Test2 ~/Test2
    • -> Experten Modus
    • -> AES 128
    • Dateisystem Blockgröße -> 1024 (Standardvorgabe)
    • Verschlüsselungsalgo der Dateinamen -> Block
    • Enable filename initialization vector chaining -> y (Standardvorgabe) (Sollte hier keine Performanceunterschiede machen, Macht sich bemerkbar, wenn man einen Ordner mit vielen Dateien darin umbennent)
    • Enable per-file initialization vectors? -> y (Standardvorgabe)
    • Enable filename to IV header chaining? -> n (Standardvorgabe)
    • Enable block authentication code headers -> n (Standardvorgabe)
    • Enable file-hole pass-through? -> y (Standardvorgabe)
    • Version 1.6
    • Siehe hier und hier (Gute Erklärungen der einzelnen Encfs optionen!).

Die 3 Testreihen:

Testreihe 1:  4 GB Große Datei aus zufälligen Zahlen

Zu kopierende Datei wurde aus zufälligen Zahlen erzeugt und war 4 GB groß.

dd if=/dev/urandom of=TestFile bs=1G count=4

Zuerst der “Vergleichsbenchmark” ohne Verschlüsselung:
Kopieren der 4 GB großen Testdatei vom Ramlaufwerk auf die (unverschlüsselte) SSD mit Hilfe von cp benötigte:

real 0m56.887s
user 0m0.080s
sys 0m9.840s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKSeCryptfsTruecryptEncFS
1. Durchgang: cp1m10.839s
0m0.040s
0m7.310s
0m59.902s
0m0.010s
0m45.470s
1m16.273s
0m0.020s
0m6.890s
2m31.021s
0m0.120s
0m22.900s
2. Durchgang: rsync1m11.369s
0m34.630s
0m19.790s
1m57.060s
0m51.650s
1m27.880s
1m13.218s
0m32.380s
0m18.940s
3m17.897s
1m19.130s
0m48.200s


 

 

 

 

Wie man sieht, schlagen sie sich eigentlich alle gut bis auf EncFS. eCryptfs ist  – unerwarteterweise – knapper Sieger mit 10 s Vorsprung. Allerdings hat eCryptfs auch am meisten System-CPU Zeit benutzt – ob die anderen besser skalieren oder ob es daran liegt, das LUKS/TC Kernelmodule fürs Ver-/Entschlüsseln nutzen, weiß ich nicht.Sobald rsync ins Spiel kommt, sind LUKS/Truecrypt auf dem Siegertreppchen, eCryptfs nur noch Mittelfeld. Klar abgeschlagen ist EncFS.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKSeCryptfsTruecryptEncFS
1. Durchgang: cp0m32.972s
0m0.080s
0m13.420s
0m33.364s
0m0.020s
0m27.440s
0m35.624s
0m0.050s
0m13.530s
0m32.959s
0m0.110s
0m12.690s
2. Durchgang: rsync1m38.643s
1m11.780s
0m38.020s
1m22.271s
0m48.010s
1m1.190s
1m37.834s
1m8.650s
0m37.230s
1m42.439s
1m17.120s
0m38.030s

 

 

 

 

 

Bei cp kaum ein Unterschied, bis auf hörere System CPU Zeit bei eCryptfs, bei rsync hingegen ist plötzlich eCryptfs der klare Gewinner, EncFS der klare Verlierer.

Für alle weiteren Testreihen hab ich nur noch cp genommen, kein rsync mehr!

Testreihe 2:  1584 Bilder

Ordner mit 1584 Bildern, insgesamt 842 MB. Bilder sind wild gemischt, große,kleine,mittlere alles dabei. Rest wie vorhin.

Zuerst wieder der “Vergleichsbenchmark” ohne Verschlüsselung:

real 0m1.882s
user 0m0.030s
sys 0m0.810s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKSeCryptfsTruecryptEncFS
1. Durchgang cp0m5.687s
0m0.020s
0m1.060s
0m8.255s
0m0.010s
0m8.170s
0m5.895s
0m0.030s
0m1.040s
0m30.084s
0m0.070s
0m4.350s


 

 

Interessant, Luks/TC liegen ganz klar in Führung, EncFS weit abgeschlagen.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKSeCryptfsTruecryptEncFS
1. Durchgang cp0m0.656s
0m0.030s
0m0.620s
0m0.742s
0m0.030s
0m0.690s
0m0.656s
0m0.030s
0m0.620s
0m5.993s
0m0.070s
0m1.810s

 

 

 

Beim Lesen umgekehrtes Bild: EncFS in Führung, eCryptFS letzter, LUKS/TC im Mittelfeld.

Testreihe 3:  5000 Dateien

Dieses Mal gibts 5000 Dateien à 512 KB (insg. ~2.4 GB) mit zufälligem Inhalt und zufälligem Dateinamen

while /bin/true; do dd if=/dev/urandom of=$( cat /dev/urandom | od -x | tr -d ' ' | head -n 1) bs=1K count=512; done

Rest wie vorhin.

Zuerst wieder der “Vergleichsbenchmark” ohne Verschlüsselung:

real 0m30.532s
user 0m0.100s
sys 0m5.440s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKSeCryptfsTruecryptEncFS
1. Durchgang cp0m42.149s
0m0.110s
0m4.140s
0m36.254s
0m0.110s
0m29.310s
0m45.088s
0m0.110s
0m4.270s
1m24.687s
0m0.230s
0m14.200s


 

 

Bekanntes Bild: eCryptFS gewinnt, LUKS/TC im Mittelgeld, EncFS abgeschlagen.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKSeCryptfsTruecryptEncFS
1. Durchgang cp
0m43.435s
0m0.220s
0m8.520s
0m32.257s
0m0.160s
0m24.220s
0m44.917s
0m0.280s
0m8.370s
0m32.346s
0m0.290s
0m8.170s

 

 

 

Beim Lesen liegen dieses Mal die dateibasierten Verschlüsselungen beide vorne, LUKS/TC 10 Sekunden dahinter.

Zusatzrunde 1:

Kopieren der 5000 Dateien aus Testreihe 3 mit Nautilus von LUKS/eCryptfs ins Ramlaufwerk.

Ergebnis: Beide gleichauf mit ~ 32 Sekunden. Unterschiede innerhalb meiner Messtoleranz. (Stoppuhr..)

Zusatzrunde 2:

Kopieren der 5000 Dateien aus Testreihe 3 mit Nautilus von LUKS/eCryptfs auf Festplatte (NTFS FORMATIERT!).

Ergebnis: eCryptfs ~ 1:46, LUKS ~ 1:33 -> LUKS 10 Sekunden schneller.

Zugegebenermaßen waren Zusatzrunde #1 und #2 nicht sonderlich genau und daher wenig aussagekräftig.

Fazit:

Nochmal alle Ergebnisse als Tabelle, jeweils Zeilenweise der Sieger/die Sieger markiert. Wenn 2 gute Ergebnisse nahe aneinander liegen, hab ich beide markiert. Markierungen nur nach Real-Zeit! System-CPU Zeit unbeachtet.

LUKSeCryptfsTruecryptEncFS
Messreihe 1
Schreiben Ram -> Crypted
1. Durchgang cp
1m10.839s
0m0.040s
0m7.310s
0m59.902s
0m0.010s
0m45.470s
1m16.273s
0m0.020s
0m6.890s
2m31.021s
0m0.120s
0m22.900s
Messreihe 1
Schreiben Ram -> Crypted
2. Durchgang rsync
1m11.369s
0m34.630s
0m19.790s
1m57.060s
0m51.650s
1m27.880s
1m13.218s
0m32.380s
0m18.940s
3m17.897s
1m19.130s
0m48.200s
Messreihe 1
Lesen Crypted -> Ram
1. Durchgang: cp
0m32.972s
0m0.080s
0m13.420s
0m33.364s
0m0.020s
0m27.440s
0m35.624s
0m0.050s
0m13.530s
0m32.959s
0m0.110s
0m12.690s
Messreihe 1
Lesen Crypted -> Ram
2. Durchgang: rsync
1m38.643s
1m11.780s
0m38.020s
1m22.271s
0m48.010s
1m1.190s
1m37.834s
1m8.650s
0m37.230s
1m42.439s
1m17.120s
0m38.030s
Messreihe 2
Schreiben Ram -> Crypted
1. Durchgang cp
0m5.687s
0m0.020s
0m1.060s
0m8.255s
0m0.010s
0m8.170s
0m5.895s
0m0.030s
0m1.040s
0m30.084s
0m0.070s
0m4.350s
Messreihe 2
Lesen Crypted -> Ram
1.Durchgang cp
0m0.656s
0m0.030s
0m0.620s
0m0.742s
0m0.030s
0m0.690s
0m0.656s
0m0.030s
0m0.620s
0m5.993s
0m0.070s
0m1.810s
Messreihe 3
Schreiben Ram -> Crypted
1.Durchgang cp
0m42.149s
0m0.110s
0m4.140s
0m36.254s
0m0.110s
0m29.310s
0m45.088s
0m0.110s
0m4.270s
1m24.687s
0m0.230s
0m14.200s
Messreihe 3
Lesen Crypted -> Ram
1.Durchgang cp

0m43.435s
0m0.220s
0m8.520s
0m32.257s
0m0.160s
0m24.220s
0m44.917s
0m0.280s
0m8.370s
0m32.346s
0m0.290s
0m8.170s
Zusatzrunde 1
~ 0m32s~ 0m32s
Zusatzrunde 2
~ 1m33s~ 1m46s

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Schlussendlich steht es gleichstand zwischen LUKS und eCryptfs.  Allerdings finde ich, zeigen LUKS und Truecrypt eine wesentlich konstantere Performance ohne große Ausreißer und bei wesentlich weniger System CPU Zeit. Da beide die gleichen Kernelmodule benutzen, ist die Performance fast immer gleich bis auf kleine Unterschiede, welche im Alltag keine Rolle spielen sollten.

Soll es ein dateibasiertes Verschlüsselungssystem sein, so muss man klar zu eCryptfs raten und von EncFS eher Abstand nehmen wegen der Performanceprobleme, welche wohl FUSE geschuldet sind. Das ist sehr schade, da EncFS eine unheimlich einfache Bedienung hat und ein absolutes Alleinstellungsmerkmal: Es kann den Ordner nach x Minuten Inaktivität automatisch Aushängen.

Beim Backup ist die Frage schon nicht mehr so leicht zu beantworten: Ich finde, EncFS ist hier der Sieger. Man kann einfach den Ordner kopieren und muss sich um nichts sorgen. Für eCryptfs spricht das prinzipiell auch, allerdings muss man hier auch dran denken die entspr. Schlüssel zu sichern und das “Restore”-Prozedere ist nicht sehr schön, siehe hier. Bei LUKS/TC bleiben einem schlussendlich 2 Varianten: 1) Container/Abbild des Laufwerkes ganz kopieren oder 2) Auf beiden Seiten verschlüsselte Medien nehmen und dazwischen kopieren.  Ich selber nutze Variante 2), da es mit Rsync weit besser klappt. Theoretisch kopiert Rsync bei Variante 1) auch nur die Veränderungen, praktisch klappt das bei 500 GB Containern nicht.

Ich persönlich wurde bei größeren Partitionen/Containern eher zu LUKS/TC raten, einfach weil die Performance konstanter ist. Für das Homeverzeichnis des Laptops hingegen ist eCryptfs beispielsweise sehr gut geeignet. Das kommt auch daher, dass eCryptfs vorallem bei SSDs besser dasteht, da im Gegensatz zu LUKS/TC hier ATA TRIM (discard) funktionieren sollte – Ubuntu bietet das von Haus aus fürs Homeverzeichnis an.

Im Archwiki findet sich aktuell eine Warnung im eCryptfs Artikel, dass eCryptfs Bugs enthält, welche zum Dateiverlust führen können und ausserdem das ganze System verlangsamen. Nachvollziehen kann ich es zwar nicht, man sollte es aber vllt. bei seiner Wahl in Betracht ziehen. (siehe auch hier)

Ausblick:

In diesem Vergleich ist das letzte Wort definitiv noch nicht gesprochen, denn mit Ubuntu 11.04 und co. wird der Kernel 2.6.38 Einzug halten und damit kommen einige Veränderungen (z.B. Verbesserungen an VFS). Ausserdem wird Dmcrypt eine bessere Unterstützung für Multicore Prozessoren bekommen, was LUKS und TC mit Sicherheit gerade recht kommt.(siehe hier)

Wenn ich Zeit habe, werde ich nochmal dann noch einmal “nachmessen”.



Zotac 9300-ITX und Nvidia 270.29 sind keine Freunde…

Wer wie ich das x-swat PPA von Ubuntu an hat, um die neusten Nvidia Treiber automatisch zu erhalten, wird sich neulich bestimmt gewundert haben, dass der Bootvorgang einfach hängen bleibt seit dem Update des nvidia-current/nivida-graphic-driver Treibers auf 270.29-0ubuntu1~maverick~xup2 vor ca. 4 Wochen, wenn er ein Zotac 9300-ITX hat.

Komischerweise fiel mir das erst jetzt auf (Vllt. lag das natürlich auch daran, dass solche Mainboards meist in HTPCs vorkommen die selten mal komplett rebootet werden.) … man findet zum Thema auch nur ein Thread aus dem März – es scheint nur Zotac 9300-ITX Nutzer zu betreffen.

Die Lösung des ganzen war jedenfalls das x-swat PPA zu löschen, per Synaptic dann die Version 260.19.06 von nvidia-current, nvidia-current-modaliases und nvidia-settings einmalig erzwingen und die Kiste ist gelöscht.

Hoffen wir nur, es gibt solche Probleme dann nicht in Ubuntu 11.04, welches in 3-4 Wochen erscheint…

Hier ist der einzige Google-Treffer zum Thema den ich gefunden habe.

Wie der User im Forum kommen bei mir im syslog ähnliche Fehler beim booten:

Apr  2 18:00:26 Ubuntu-PC kernel: [   19.422620] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  270.29  Wed Feb 23 16:18:35 PST 2011
[..]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514328] BUG: unable to handle kernel NULL pointer dereference at 0000000000000a48
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514330] IP: [] _nv008358rm+0xf1/0x115 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514559] PGD 1085ce067 PUD 10879e067 PMD 0 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514561] Oops: 0000 [#1] SMP 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514563] last sysfs file: /sys/bus/acpi/drivers/NVIDIA ACPI Video Driver/uevent
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514565] CPU 1 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514566] Modules linked in: dm_crypt snd_hda_codec_nvhdmi snd_hda_codec_realtek lnbp21 tda826x tda10086 nvidia(P) dvb_usb_ttusb2 dvb_usb shpchp dvb_core psmouse serio_raw snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc i2c_nforce2 joydev coretemp lp parport ahci video libahci output forcedeth
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514580] 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514582] Pid: 1398, comm: Xorg Tainted: P            2.6.35-28-generic #49-Ubuntu MCP7A/MCP7A
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514583] RIP: 0010:[]  [] _nv008358rm+0xf1/0x115 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514698] RSP: 0018:ffff88010862f898  EFLAGS: 00010246
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514699] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514701] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8801086e2000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514702] RBP: ffff8801079e5d80 R08: ffff880107a0c000 R09: ffff880107a82350
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514704] R10: 0000000000000021 R11: 0000000000000021 R12: ffff880107aa8000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514705] R13: 0000000000000000 R14: ffff8801086e2000 R15: ffff880107a0c000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514707] FS:  00007f69ff42f840(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514708] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514709] CR2: 00007fae8eb21900 CR3: 0000000108788000 CR4: 00000000000006e0
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514711] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514712] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514714] Process Xorg (pid: 1398, threadinfo ffff88010862e000, task ffff8801085fadc0)
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514715] Stack:
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514716]  0000000000000000 ffff8801086e2000 ffff880107aa8000 ffff880107a0c000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514718] <0> 0000000000000000 ffffffffa0237211 0000000000000000 ffff880107aa8000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514719] <0> ffff880107aa8000 ffffffffa01ff507 ffff880107aa8000 ffff8801086e2000
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514722] Call Trace:
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514837]  [] ? _nv008171rm+0x54/0x60 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.514945]  [] ? _nv022281rm+0x1b6/0x33f [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515059]  [] ? _nv022279rm+0x94/0xbb [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515157]  [] ? _nv007553rm+0xde/0x109 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515255]  [] ? _nv007552rm+0x1a3/0x1dc [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515358]  [] ? _nv007881rm+0x287/0xd97 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515458]  [] ? _nv007550rm+0x96/0xa2 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515558]  [] ? _nv018936rm+0xaef/0xe79 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515678]  [] ? _nv009746rm+0x1a0/0x22f [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515790]  [] ? _nv009743rm+0x2e/0x62 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.515934]  [] ? _nv014790rm+0x27b/0x4c3 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516078]  [] ? _nv015086rm+0xe9/0x165 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516151]  [] ? _nv015263rm+0xd/0x12 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516276]  [] ? _nv002397rm+0x17b/0x271 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516397]  [] ? _nv002391rm+0x4a5/0x685 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516519]  [] ? rm_init_adapter+0x9d/0x111 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516641]  [] ? nv_kern_open+0x374/0x6a0 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516645]  [] ? chrdev_open+0x10a/0x200
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516647]  [] ? chrdev_open+0x0/0x200
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516650]  [] ? __dentry_open+0xe5/0x330
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516653]  [] ? security_inode_permission+0x1f/0x30
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516655]  [] ? nameidata_to_filp+0x54/0x70
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516657]  [] ? finish_open+0xe8/0x1d0
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516660]  [] ? dput+0xdf/0x1b0
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516661]  [] ? do_last+0x86/0x460
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516663]  [] ? do_filp_open+0x21b/0x660
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516665]  [] ? alloc_fd+0x10a/0x150
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516667]  [] ? do_sys_open+0x69/0x170
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516669]  [] ? sys_open+0x20/0x30
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516672]  [] ? system_call_fastpath+0x16/0x1b
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516674] Code: 00 ff 97 b0 01 00 00 85 c0 49 0f 45 dc be 8e 2c 00 00 4c 89 ff 41 ff 97 90 00 00 00 ba 00 00 00 00 85 c0 75 0e 48 89 de 4c 89 f7  93 48 0a 00 00 89 c2 85 d2 0f 94 c0 0f b6 c0 89 83 04 14 00 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516687] RIP  [] _nv008358rm+0xf1/0x115 [nvidia]
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516801]  RSP 
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516802] CR2: 0000000000000a48
Apr  2 18:00:27 Ubuntu-PC kernel: [   20.516804] ---[ end trace 35a794b8ae81ac1d ]---

Da es dafür kein Launchpad Bug Report gibt, habe ich hier einen geöffnet.