Blog

*gnaaaaaah* Ist es zuviel verlangt?! Schon klar, daß man für so große Auflösungen wie 2560*1440 einen Dual-Link DVI braucht. HDMI1.3 sollte das ja auch unterstützen. Aber wenn sich ein Monitor weigert, auf einem HDMI Port diese Auflösung zu fahren, obwohl alle Beteiligten damit klarkommen sollten, nur eben nicht der HDMI Eingang des Monitors (dessen native Auflösung das übrigens ist), dann wird mir schon irgendwie anders. Zumal 1920*1200 (höchste angebotene Auflösung über HDMI) auf dem Monitor echt unschön aussieht. Dell wollte sich wohl Besseres sparen um ihre DisplayPort Verbindungen zu pushen?!

Am Ende ist der Grund aber irrelevant, denn selbst mit dem Monitor ist es möglich, mit etwas Zuwendung 2560*1440 zu fahren, wenn auch leider nur mit 35,2 Hz Wiederholfrequenz. In meinem Setup (Arbeitsrechner) ist das aber gut nutzbar. Flimmert ja nicht wie früher.

Machbar ist das ganze entweder über manuelle Konfiguration in der xorg.conf (das überlasse ich dem geneigten Leser selber) oder über xrandr:

xrandr --newmode "2560x1440_35.2" 148.500000 2560 2648 2692 2840 1440 1442 1447 1485

Mit dem Aufruf fügen wir eine neue Modeline zur laufenden Config hinzu. Diese Modeline kann auch für die xorg.conf Methode benutzt werden, muß dann halt nur in die entsprechende Screen-Sektion eingesetzt werden.

xrandr --addmode HDMI-0 "2560x1440_35.2"

Damit fügen wir dem HDMI Ausgang mit dem Label „HDMI-0“ den neudefinierten Modus hinzu. Das Label kann differieren, kann man aber mit einem Aufruf von xrandr ohne Parameter einfach herausfinden.

xrandr --output HDMI-0 --mode 2560x1440_35.2

Und so aktiviert man die neue Auflösung auf dem entsprechenden Ausgang. Das könnte man z.B., auch mit ARandr machen, wenn man sich die Tipparbeit sparen möchte. Nachdem man die Modeline hinzugefügt und auf den gewünschten Ausgang gebunden hat, kann jede auf der Randr Erweiterung aufbauende Applikation die neue Auflösung nutzen, sie taucht also ab da auch in Konfigurationstools des persönlichen Desktop-Environments auf.

Bei mir am Institut betreiben wir unser WLAN – wie so viele Andere in der Welt – mit RADIUS-gestützter 802.1X Authentifizierung und WPA2 Verschlüsselung. Das funktioniert inzwischen wunderbar mit allen Betriebssystemen, ein Zustand, der durchaus schön ist, bedenkt man doch wie schwer es in den Anfangszeiten teilweise war, Systemen 802.1X beizubringen.

Nun haben wir auf Android Geräten ein interessantes Verhalten bemerkt. Teilweise kommt es zu Fehlern beim Verbindungsaufbau mit dem WLAN, insbesondere bei der Authentifikation mit 802.1X. Die Geräte verbinden sich, authentifizieren sich und brechen den Vorgang ab, nur um das ganze in ewiger Schleife zu wiederholen, mehrfach in der Sekunde. Dabei springen sie sogar von Accesspoint zu Accesspoint. Das Problem tritt bei verschiedensten Geräten auf, augenscheinliche Gemeinsamkeiten gibt es nicht wirklich. Die Android Version ist da ebenso insignifikant gewesen wie das verwendete ROM (müsste es nicht eigentlich im Geiste von Linux auch bei Android „Distribution“ heißen?!).

Ich habe den Fehler lange nicht zu fassen bekommen, aber gestern wurde es mir zu doof, ich habe mir die Sourcen vom wpa_supplicant und vom Linux-Kernel geschnappt und habe das Problem bis zum ioctl herunter verfolgt, wo das Problem entsteht. Dabei viel mir auf, dass an genau dieser Stelle weder etwas mit WPA/WPA2 noch mit 802.1X geschieht, sondern der WLAN-Hardware ein WEP Schlüssel mitgeteilt werden soll. Genau das schlägt fehl.

Aus drivers/staging/brcm80211/brcmfmac/wl_cfg80211.c, Funktion wl_cfg80211_config_default_key:

if (wsec & WEP_ENABLED) {
    /* Just select a new current key */
    index = (u32) key_idx;
    index = htod32(index);
    err = wl_dev_ioctl(dev, WLC_SET_KEY_PRIMARY, &index,
            sizeof(index));
    if (unlikely(err)) {
        WL_ERR(("error (%d)\n", err));
    }
}

Der rot markierte Call ist das Problem. Nun gehört das File ja zum Broadcom Treiber, und die verwendete Kernelversion ist auch nicht die aktuellste, aber ich kann auf meine APs schneller einwirken als auf den Kernel meines Telefons. Aber viel wichtiger: WEP fällt eh in die Kategorie „muß schnell weg“, daher habe ich die APs im ganzen Institut umkonfiguriert und habe die als Fallback für hoffnungslos veraltete Geräte noch aktivierte WEP Option endgültig abgeschaltet. Und siehe da, die Android Geräte hatten auf einmal keine Probleme mehr mit WPA2 und 802.1X.

Ich nehme an, daß es sich um ein aktives Probing von Cryptofähigkeiten der aktuellen SSID handelt, aber ich kann mich da auch vertun – ich hatte wenig Motivation mich noch tiefer in die Kernelsourcen einzugraben. Zumindestens habe ich die Quelle dieses Problems gefunden und eliminiert. Dieser Fehler scheint anderswo auch aufgtetreten zu sein, ich habe diverse Verweise auf vergleichbares Verhalten von Adroid Geräten im Netz gefunden, aber nie eine hilfreiche Lösung. Vielleicht findet ja der eine oder andere diesen Artikel und spart sich so harte Detektivarbeit auf tiefster Systemebene.

Wenigstens geben mir solche Erfolge immer wieder mal das Gefühl, doch den richtigen Beruf eingeschlagen zu haben. 😉

Da es mir jetzt zum wiederholten Male auf die Nerven ging, wird es Zeit es hier zu posten. Wenn man ein anderes Desktop Environment benutzt als GNOME, dann wird der Desktop von GNOME automatisch als normales Fenster gestartet, sobald man den Nautilus-Dateimanager benutzen will. Das verdeckt dann eine Menge nützlicher Informationen. Dem kann unter Ubuntu 13.04 aber wie folgt Abhilfe geschaffen werden:

$ gsettings set org.gnome.desktop.background show-desktop-icons false

Der Desktop sollte sofort verschwinden und alles ist wieder so wie es sein sollte.

An dieser Stelle ist vielleicht ein kleiner Rant angebracht: die GNOME Truppe hat sich ganz schön ins eigene Fleisch geschnitten mit Ihrer ständigen Wechslerei von config-Backends. Heutzutage weiß man echt nicht mehr, welches Backend man eigentlich benutzen soll, um primitivste Settings zu ändern, die man früher mal in einfachsten Dialogen managen konnte. Wann ist es eigentlich zur Gewohnheit geworden, Benutzern Optionen wieder wegzunehmen? Als ich mit Open Source Software angefangen habe, ging es noch darum, dem Benutzer mehr Möglichkeiten und Freiheit zu geben… 😛

Ich habe Apple ja inzwischen schon schwer satt, auch wenn ich jahrelang treuer Mac OS X Nutzer war. Heute hat diese Firma allerdings noch einen drauf gesetzt was Ihr negatives Ansehen bei mir angeht.

Ich wollte meine Mailarchive durchsuchen und mir fiel dabei auf, dass ich die ganzenn alten Mails noch gar nicht alle auf meine aktuelle Linux Installation migriert hatte. Nachdem ich dann also die alten Dateien von einem Backup meines eingemotteten iMac extrahiert hatte, stand ich vor dem Problem, dass Apple Mail die Mails nicht mehr im gewohnten Format von viel Früher [tm] gespeichert hat, sondern mit Mail V2.0 auf ein neues Mailboxformat umgestellt hat.

Sämtliche Versuche mit frei verfügbarer Konversionssoftware und Importiertools schlugen fehl. Nicht mal mit einer laufenden Apple Mail Version habe ich die Mails noch importiert bekommen, um sie über Umwege aus einer aktiven Mail Installation in ein verwertbares Format zu extrahieren, anscheinend speichert Apple die Mails inzwischen Hostabhängig, der Host wird hierbei offenbar mit einem Hashwert in der Verzeichnisstruktur repräsentiert. Die Mail-eigene Importfunktion für das Hausformat versagte vollends und ließ nur leere Verzeichnisse entstehen.

Ich habe dann nicht weiter gefackelt und habe mir mal wieder selbst beholfen. Die einzelnen Mails sind in *.emlx Dateien gespeichert, von denen beginnt jede mit einer Zeile, die nur eine Zahl enthält. Danach kommt die Mail mit allen Headern im Klartext. Abschließend gibt es noch einen XML-Block, der Metainfos zur Mail enthält.

Man muss also nur die Zahl am Anfang entfernen, den XML-Block wegwerfen und dann alle Mails hintereinanderhängen, um mit minimalen Zusatzinfos (der From-Zeile und ein paar Leerzeilen) eine mbox Datei aus den ganzen Mails zu zaubern. Ein schnelles Perl Script als Filter erledigte das Umschreiben der einzelnen Mails:

#!/usr/bin/perl

use strict;

# Wurde der XML Block gefunden? Dann $xmlfound=1
my $xmlfound=0;

# speichert die relevante Mail für die Ausgabe
my $mail="";  

# erste Zeile ignorieren
my $firstnumber=<>;

# speichert Datum und Sender für die einleitende From-Zeile des mbox Formates
my $date="";
my $sender="";

# solange der XML-Block nicht gefunden wurde:
while($xmlfound==0) {

        # Lese die nächste Zeile aus stdin
        my $momline=<>;

        # ist die aktuelle Zeile der Beginn des XML-Blocks? Dann bereite das Aussteigen aus der Schleife vor
        if ($momline=~/[<][?]xml/) { $xmlfound=1; }
        else {
                # From: Header als Absender auslesen
                if ($momline=~/^From:.*<(.*)>/) {
                        $sender=$1;
                }

                # Date: Header als Absendedatum einlesen
                if ($momline=~/^Date: (.*)$/) {
                        $date=$1;
                }

                # Sollte im Text ein Klartext "From" am Zeilenanfang stehen,
                # stelle ein '>' voran, um das mbox format nicht zu durchbrechen.
                # speichere die aktuelle Zeile im Mailbuffer.
                if ($momline=~/^From .*$/) {
                        $mail.=">".$momline;
                } else { $mail.=$momline; }

        };

};

# Stelle die From Zeile voran...
print("From ".$sender." ".$date."\n");
# ...gib die relevante Restmail aus...
print($mail);
# ...und schließe die Mail sicherheitshalber noch mal mit expliziter Newline ab.
print ("\n");

(Jaaaajaaa, der Code ist ineffizient, aber das ist Fire-and-forget-Code, der muß exakt einmal funktionieren und fliegt dann in die Tonne. Bei anderen Projekten schreibe ich besseren Code. 😉 )

Jetzt wechselt man in das Verzeichnis, in deren Unterverzeichnissen man alle vorhandenen *.emlx Files konvertieren will und filtert z.B. so (für die bash):

for mailx in $(find -type f | grep [.]emlx$); do cat $mailx | ~/bin/emlx-filterpl >> 'Inbox-2006.mbox'; done;

Jetzt hat man im aktuellen Verzeichnis eine Datei (im obigen Beispiel Inbox-2006.mbox), die man problemlos in Thunderbird installieren kann. Ich habe dazu das ImportExportTools-Addon benutzt. Nach extrem kurzer Laufzeit hatte ich >3Gb an Mailarchiven importiert. ich hoffe, ich kann mit dem Skript anderen in meiner Situation die Nerven ersparen, die mich dieser Nachmittag gekostet hat. 😉

Ich weiß nicht wie oft ich inzwischen beim Tippen auf der on-screen Tastatur bei meinem Galaxy Tab versehentlich statt auf der Leertaste auf der Mini-app Taste gelandet bin. Und schon hängt einem diese App-Bar in der Sicht. Dazu tauchen zusäzliche Buttons in der Navbar ständig so nah an dem Mini-app Button auf, dass man nie ganz sicher sein kann, welchen Button man denn jetzt gleich erwischt, wenn man den Finger zum Zielanflug absenkt.

Grundsätzlich baut Samsung tolle Android Versionen. aber diese App-Bar, die hätten sie sich echt sparen können, oder zu mindestens mehr Optionen anbieten sollen, das Ganze zu personalisieren… Es wäre ja schon toll gewesen, wenn man den Button einfach nach ganz rechts oder ganz links hätte legen können, anstatt ihn immer mittig direkt unter der Spacetaste zu positionieren.

Ich war eigentlich ausreichend glücklich mit der Android-Version auf meinem Tablet, aber hat mich dieser Button so genervt, dass ich doch wieder zum rooten greifen musste. Netterweise hat sich das Menü schnell entfernen lassen; Dazu benötigt man nur einen Dateimanager mit root Rechten, z.B. den ES Datei Explorer.

Dem muss man dann über die root-explorer Funktion mitteilen, das er bitte die /system Partition read/write mounten soll. Mit dem neuerworbenen Schreibzugriff muss man nur noch die Dateien /system/framework/minimode.jar und /system/framework/minimode.dex löschen. Nach einem anschließendem reboot oder einem restart des präferierten Launchers ist der verhasste Button dann endlich weg.

Wer noch auf die paar kb Wert legt, kann noch aus /system/app alle Applikationen löschen, die ein „mini“ enthalten, dann sind alle Reste herausgepflückt. Wenn man fertig ist, sollte man noch die Partition wieder r/o remounten, damit wieder alles schön sicher beim Alten ist.

Aber auch hier gilt, wie von miketoasty im Originalpost schon gesagt: alles geschieht auf eure eigene Gefahr, wer sich sein Tablet kaputtmacht, ist selber schuld. 😉

Rückgängig machen ist bei der Sache allerdings eher schlecht, dann sollte man sich die Dateien vielleicht aufbewahren oder in ein installierbares Zip basteln, um es mit CWM wieder zu reinstallieren. Ich lege allerdings keinerlei Wert darauf, den Mist wieder zu sehen und sage nur : good riddance, mini-app bar!