Christophs Blog

Ich besitze ein Thinkpad X121e mit der AMD E-450 APU sowie der MiniPCI-Express WLAN Karte RTL8188CE von Realtek.

Damit hatte ich erst keine Probleme – zumindest Zuhause im WLAN. Doch in der Uni hatte ich ständig Probleme. Entweder hat es ewig gedauert bis es verbunden hat oder ich bin ständig rausgeflogen bzw. war noch im Netzwerk aber bekam keine Verbindung mehr zu anderen Servern. Ich habe es ja immer damit abgetan, dass das Uni WLAN Linuxfeindlich sei. Das lag vor allem daran, dass ich bei den Laptops vorher auch schon Probleme hatte und diese auch von dem ein oder anderen gehört habe. Beim Thinkpad war es aber am schlimmsten.

Irgendwann hat mich das so aufgeregt, sodass ich länger nach Lösungsmöglichkeiten gesucht hatte. Es wird immer empfohlen unter Linux die Stromsparmechanismen des WLAN Modules zu deaktivieren. Das half leider nichts. Irgendwann hatte ich gelesen, man solle auch im BIOS mal die Stromsparmechanismen des pci-e Bus deaktivieren. Da bildete ich mir ein, dass es besser geworden ist. Aber es gab dann doch wieder Phasen, bei denen es besonders schlimm war. Ich hatte auch schon versucht den Realtek Treiber selber zu kompilieren, aber es kam mit dem neusten Kernel zu Fehlern, die andere auch nicht gelöst bekommen hatten.

Also noch einmal gesucht und dann doch eine recht „drastische“ Lösung gefunden: Die Leute haben die Realtek WLAN Karte durch eine von Intel getauscht. Problem hierbei war nur, dass bei AMD Boards im BIOS Karten von bestimmten Herstellern gesperrt sind – u.a. von Intel. Die Lösung ist: Die alte Karte raus und die neue in den WWAN/UMTS Slot stecken. Dies habe ich auch gemacht: Ich habe mir die Intel Centrino Advanced-N 6200 AGN (ja sie heißt da anders, aber das ist sie) für 20€ geholt. Da bei einem Suspend das WLAN aber nicht mehr angeht, musste ich noch PIN 20 abkleben. Das habe ich mit einem kleinen Stück Klebestreifen gemacht – war sehr auswendig, aber funktioniert. Außerdem muss man die Karte mit Klebestreifen oder ähnliches fixieren, da die Karte nur halbe Länge hat, der Slot aber volle Länge. Dafür gibt es aber Adapter – davon werde ich mir demnächst mal einen kaufen.

Jetzt funktioniert das WLAN auch im Uni Netz super. Natürlich gibt es manchmal Probleme, aber glaube das liegt wirklich am Uni WLAN. ^^ Suspend funktioniert nun auch. Gut manchmal doch nicht, aber schon mal viel besser als vorher. Ich werde dem mal nachgehen.

Seit zwei bis drei Wochen nutze ich nun die Nightlies von CyanogenMod 11.0. Vorher hatte ich die Nightlies von CM 10.2 bzw. dann die Stable. Da nun die Weihnachtspause in Aussicht stand und im CyanogenMod Forum die berichteten Bugs immer weniger wurden, war es für mich an der Zeit die neuen Nightlies von CM 11 zu installieren. Generell sollte man sich immer bei neuen CM Versionen in das Forum schauen. Dort gibt es meist ein Thread zur Sammlung von Bugs. Auch auf Google+ oder anderen Netzwerken kann man verfolgen, ob sich der Umstieg schon lohnt. Besonders am Anfang gibt es immer viele Bugs, die meistens mit Abstürzen oder das Nichtfunktionieren von Telefon und Kamera zu tun haben.

Da ich in mehreren Kommentaren noch lese, dass Leute Probleme mit CM 11 haben, muss ich etwas vorweg sagen: Ich habe dieses mal vor dem Flashen ein Factory Reset gemacht. Das heißt: Alle Daten weg. Das sollte man bei Upgrades auf neue Versionen (nicht die Nightlies) eh machen. Wenn man eine entsprechende Backup App wie Titanium Backup o.ä. benutzt, dann ist das auch kein Problem. Außerdem habe ich die neusten Google Apps aus Dezember genommen. Oft gab es bei Leuten Probleme, wenn sie die von November genutzt hatten. Ob da wirklich ein Zusammenhang besteht, weiß ich nicht.

Und wie läuft’s? Es läuft super. Eigentlich funktioniert alles. Ich hatte am Anfang nur das Problem, dass der Notification Sound zu laut war. Ich konnte es immer auf niedrigste Stufe stellen, aber es war trotzdem zu laut. Erst als ich in den Einstellungen eingestellt hatte, dass die Notification Sounds und das Klingeln getrennt einstellbar sein sollen, funktioniert es auch wie gewollt. Außerdem stürzt manchmal die Kameraapp ab bzw. lässt das Smartphone rebooten, aber so oft ist das nicht – gut, ich benutze die Kamera auch nicht soo oft. In den Android Einstellungen fehlen glaube ich auch ein paar Optionen, aber vermissen tue ich diese eigentlich nicht.

Interessant finde ich, dass der Akku wieder länger hält. In letzter Zeit (bei CM 10.2) ging er ziemlich rasch runter. Vielleicht lag es auch an dem Kernel, der mir erst geholfen hatte. Jedenfalls habe ich ihn bei CM 11 (noch) nicht installiert.

Ich installiere nun fast täglich die neuen Nightlies und habe bisher keine Probleme.

Vor kurzem habe ich ein neues Firefox Profil angefangen, da beim alten der Browser oft abgestützt ist. Jetzt brauchte ich aber mein Client-Zertifikat vom alten Profil wieder, weil ich mich damit bei cacert.org einloggen wollte.

Beim letzten mal habe ich einfach Firefox mit dem alten Profil gestartet und innerhalb von Firefox das Client-Zertifikat exportiert. Das war mir aber zu umständlich. Sicher könnte man auch die ganze Zertifikatsdatenbank vom alten Profil in das neue kopieren, aber das wollte ich auch nicht. Also habe ich ein wenig im Internet gesucht und eine Lösung gefunden:

Erst einmal muss man wissen wo das Profil ist. Wenn man das selbe Problem wie ich hat, dann weiß man das eigentlich. Unter Linux befindet sich es in einem Unterordner von „~/.mozilla/firefox/“. In der „profiles.ini“ steht, welches Profil das Standardprofil ist.

Für die nächsten Operationen benötigt man die Programme „certutil“ und „pk12util“. Bei ArchLinux befinden sie sich im Paket „nss“, welches bei mir bereits installiert war.

Nun listet man innerhalb des Profils (also der Unterordner) alle „private keys“ auf:

% certutil -K -d ./
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa      617508...   Christoph Giesel's Root CA ID

Der Parameter „-K“ listet alle „private keys“ auf und mit „-d“ gibt man an, in welchem Verzeichnis sich die „cert8.db“ Datei befindet. Jetzt wissen wir, wie unser Zertifikat heißt. Damit können wir es exportieren:

% pk12util -o ~/export.pk12 -n "Christoph Giesel's Root CA ID" -d ./ -W passwort
pk12util: PKCS12 EXPORT SUCCESSFUL

Mit dem Parameter „-o“ sage ich, wo der Export gespeichert werden soll (also bei mir im Homeverzeichnis), mit „-n“ wie das Zertifikat heißt, mit „-d“ wieder das Verzeichnis der „cert8.db“ Datei und mit „-W“ wird ein Passwort für den Export angegeben. Da Firefox beim Import nach einem Passwort fragt, habe ich hier auch eins angegeben. Man kann es wohl auch weglassen.

Nun kann man direkt in Firefox unter „Einstellungen -> Erweitert -> Zertifikate -> Zertifikate anzeigen -> Ihre Zertifikate -> Importieren“ das Zertfikat wieder importieren. Oder man macht es ebenfalls mit pk12util (nicht getestet):

% pk12util -i ~/export.pk12 -d ./ -W passwort

Natürlich muss man hier das Verzeichnis des neuen Profils angeben. 😉

Vor kurzem habe ich den Server der Piratenpartei Sachsen-Anhalt geupdated (Debian: squeeze -> wheezy) und seit dem funktionierte das nächtliche Backupscript nicht mehr, welches duplicity nutzt.

Bei dem Update wurde duplicity auf die Version 0.6.18 geupdated. Leider hat diese Version den Bug, dass der Zugriff auf den Backupserver per SSH und einem anderen Port als 22 nicht mehr funktioniert.

Als Fehler kam:

BackendException: ssh connection to backup-host.de:23 failed: Unknown server [backup-host.de]:23
06:03:22.071 Task ‚BKP‘ failed with exit code ’23‘.

Die einfachste Möglichkeit für mich war: Eine neuere duplicity Version benutzen. Ich habe die Sourcen des duplicity Pakets aus den Quellen von Debian sid genommen und diese mit Debian Werkzeugen kompiliert.

Hierzu habe ich temporär folgende Zeile in /etc/apt/sources.list eingetragen:

deb-src ftp://mirror.manitu.net/debian sid main contrib non-free

und

apt-get update

ausgeführt.

Dann einfach folgende Befehle eingegeben:

mkdir debianbuild
cd debianbuild
apt-get build-dep duplicity
apt-get source duplicity
cd duplicity-0.6.22
dpkg-buildpackage -us -uc -nc
cd ..
dpkg -i duplicity_0.6.22-2_amd64.deb

Schon ist die neue duplicity Version installiert und alles funktioniert wie immer. Jetzt kann man die eingefügte Zeile in /etc/apt/sources.list wieder entfernen, wenn man möchte.

In letzter Zeit habe ich mich über den Akkuverbrauch meines Smartphone aufgeregt. Selbst im normalen Standby hat es zu viel Strom verbraucht.

Ich habe zwei Lösungen für mich gefunden:

Deaktivierung von „WLAN- & Mobilfunknetz-Standort“

Zum einen habe ich in den Einstellungen unter „Standortzugriff“ die Option „WLAN- & Mobilfunknetz-Standort“ deaktiviert. Anscheinend fragen irgendwelche Google Dienste ständig meinen Standort ab und wecken daher das Smartphone. In einem Google+ Post hatte ich gelesen, dass wenn man sich bei Google Maps ausloggt, diese Abfragen nicht mehr ausgelöst werden. Ich werde hier aber noch einmal genauer nachforschen.

Boeffla-Kernel

Außerdem habe ich zum ersten mal einen alternativen Kernel installiert. Also ich benutze ja eh schon die nightly ROMs von CyanogenMod. Nun habe ich aber den Boeffla-Kernel in der Version 2.0-beta3 installiert. Laut Aussage des Entwicklers ist dieser weniger auf Leistung oder Energiesparen ausgelegt, sondern auf Stabilität. Auf Google+ hatte ich aber schon gelesen, dass bei einem anderen Benutzer der Akkuverbrauch vor allem im Standby gesunken ist. Und das wollte ich auch.

Für den Kernel habe ich im Play Store die App Boeffla-Config V2 installiert. Dort habe ich dann den CPU Goveneor auf „zzmoove“ mit dem Profil „zzmoove – optimal“ gestellt. Dieser soll batteriefreundlicher sein. Dies ist er anscheinend auch. Weitere Einstellungen habe ich nicht vorgenommen. Auf der Seite vom Kernel sind die einzelnen Optionen recht gut beschrieben.

Resultat

Die hier genannten Schritte habe ich gestern Abend durchgeführt und dann mein Smartphone geladen. Das S3 war nun fast 13h an, wo er zum einen Nachts im Standby lag und auch so von mir bedient wurde. Und nun ist der Akkustand bei 73%. Ich finde das gut. Ich werde aber noch weiter optimieren.

Update:

Ich habe nun mein S3 bis zum Akkustand von 9% nicht geladen. Bis dahin hat der Akku 1 Tag 9 Stunden 14 Minuten gehalten. Dabei war WLAN und Mobilfunk die ganze Zeit an. Es lagen aber auch zwei Nächte dazwischen. Eine Stunde Podcast habe ich gehört, habe öfters in die Facebook und Twitter App geschaut und bin auf Webseiten mit der Firefox App gewesen. Für mich ist die Akkulaufzeit echt gut. Interessant wäre es, wie lange das S3 ohne WLAN+UMTS sowie ohne Podcasts hält. Aber das werde ich wohl nie testen. ^^