planetknauer.net

So, dieses Jahr hatte ich ja schon viel Spass mit Telefonen. Erst verreckt das Samsung S5 mal so ganz spontan in den Ferien. Als Ersatz gab es dann das günstigste vor Ort erhältliche Telefon (Neo Spark), welche sich als Zwischengerät ganz gut macht, aber langfristig nicht brauchbar ist (zu schlechtes Display, zu lahmer Prozessor). Dann spinnt plötzlich mein noch keine zwei Monate altes Moto Z...

Aber wenn ich jetzt schon frustriert losrante, dann richtig. Holen wir also zum Rundumschlag gegen die Elektroschrotthersteller aus. In Sachen mobiler Kommunikations- und Unterhaltungszentralen mit staatlicher Komplettüberwachungsschnittstelle hat man heute grundsätzlich die Wahl zwischen teuren und billigen Geräten. Und die sind in ihren Vor- und Nachteilen diametral gegensätzlich.

Billige Geräte haben neben dem tiefen Preis ihre Vorteile:
+ SD-Kartenslot
+ DualSIM
+ Klinkenbuchse für Kopfhörer
+ wechselbare Akkus
+ weitgehend unmodifiziertes Android
+ relativ robuste Bauweise
Aber irgendwie müssen die niedrigen Preise gerechtfertigt werden:
- mieses Display, wovon man blind wird. Dazu ist die Auflösung so gering, dass diverse Apps nicht installierbar sind.
- lahmer Prozessor und wenig RAM
- keine Android-Sicherheitsupdates (sell&forget)
- meist kein 4G oder andere brandaktuelle Funkübertragungsmodi

Teure Geräte weisen hingegen folgende Pluspunkte auf:
+ gutes Display mit hoher Auflösung, schöner Farbwiedergabe und Lesbarkeit bei Tageslicht draussen
+ zeitgemäss schneller Prozessor
+ mit etwas Glück während bis zu zwei Jahren alle paar Monate ein Android-Sicherheitsupdate, das ausgewählte Sicherheitslücken stopft
+ mit noch etwas mehr Glück gibt es alternative ROMs, die auch noch Jahre später im Wochentakt Updates veröffentlichen
Doch nicht alles was glänzt ist Gold:
- fest verbauter Akku mit viel zu kurzer Laufzeit
- SD-Kartenslot wird zum selten gewordenen Fundstück
- DualSIM? Vielleicht gegen ganz happigen Aufpreis. Und dann nur im Austausch gegen die SD-Karte
- grausam verunstaltete und unbedienbare Herstelleroberfläche (die dann als Ausrede dafür dient, Sicherheitsupdates viel zu spät oder gar nicht zu veröffentlichen)
- tonnenweise unnütze, nicht deinstallierbare Bloatware, welche den internen Speicher vollmüllt
- immer öfter eine fehlende Klinkenbuchse
- filigran-empfindliche Bauweise (Displays gehen bis über den Rand, Komponenten mangelhaft verbunden, Elektronik geht schon beim Anschauen kaputt)

Doch mal kurz der Reihe nach. Was war mit dem S5? Das Display hatte schon länger einen Wackelkontakt, nachdem das Telefon einen Sturz aus 80cm Höhe auf einen Turnhallenboden (die sind relativ weich...) erdulden musste. Es ist mir in sitzender Position aus der Hosentasche gefallen. Und ein paar Monate später so mitten in Dubrovnik beschloss der Wackelkontakt jetzt permanent keinen Kontakt zu geben. Da ich LineageOS installiert hatte, war natürlich auch die Garantie futsch. Die Reparatur würde gleich viel wie ein Neugerät kosten. Also ab in die Tonne damit.

Was war nun mit dem Moto Z? Nun, Ich war wieder einmal unterwegs und hatte grobfahrlässigerweise vergessen, ein Backup-Telefon mitzunehmen. Das Gerät wurde auf dem Flug von Zürich nach Dubai noch etwas zum Musikhören (Musik liegt auf der SD-Karte) genutzt. In Dubai habe ich den Anschlussflug gesucht und dafür mit dem Telefon auf der Flughafenwebseite das Gate ausfindig machen wollen. Plötzlich zeigt Firefox keinen Inhalt sondern nur noch eine schwarze Fläche an. Hmm, na gut, Flughafenseite futsch? Nein, tritt auch sonstwo auf. Also gut, Firefox neu gestartet. Problem bleibt. Na schön, Methode Windows angewendet und das Telefon neu gestartet. Ganz dumme Idee. Ab jetzt hängt das Gerät im Reboot Loop. Per Zufall in den Bootloader gelangt. Cache Reset. Nützt nix. hmmm. Schweren Herzens Factory Reset durchgeführt. Nützt nix. Also gut, SIM/SD-Tray raus. Geht wieder. FUCK YOU! Herumgespielt. Mit SD ohne SIM: Reboot Loop. Mit SIM ohne SD: startet.
Na schön, dann müssen wir halt den ganzen Drecksmüll wieder neu installieren, um das Gerät wieder benutzen zu können. Aber nein, das geht nicht. Das Flughafen-Wifi verlangt Authentifizierung. Der Setup-Manager kann aber keine Wifi-Login-Portalseiten anzeigen und weigert sich ohne funktionierende Internetverbindung das Gerät einzurichten. Überspringbar ist er auch nicht, es muss zwingend ein Google-Konto hinzugefügt werden. Danke Google. Danke Motorola. Alle Daten umsonst verloren und das Telefon taugt bis auf weiteres nur noch als Briefbeschwerer.
Immerhin: Das Herstellerandroid ist nicht komplett unbenutzbar, so dass ich es bislang ohne LineageOS ausgehalten habe. Daher ist noch Garantie drauf. Mal schauen, wie viele Monate es dauern wird, den Rotz repariert zu bekommen.

War denn nun die SD-Karte kaputt? Nein, ein Test unter Linux und einem anderen Android-Telefon zeigt, dass die Karte einwandfrei ist. Im Gegentest mit anderen SD-Karten bleibt der Bootloop reproduzierbar. Aber selbst wenn: Es darf nicht sein, dass wegen so einer Lappalie wie eine(r/m) defekten SD- oder SIM-Karte(nslot) das System anfängt merkwürdige Verhaltensweisen zu zeigen oder sogar nicht mehr starten kann. Das ist eindeutig ein Versagen der Entwickler von entweder Google oder Motorola oder beiden. Jedes lumpige Desktop-Betriebssystem bekommt es fertig, bei fehlerhaften externen Datenträgern noch irgendwie zu starten, oder zumindest eine halbwegs aussagekräftige Fehlermeldung auszugeben. Sogar Windows kann das seit 20 Jahren.

Da das Gerät gerade mal zwei Monate alt geworden ist, kann ich nur spekulieren, dass der für geplante Obsoleszenz zuständige Entwickler bei Motorola geschlampt und sich in der Einheit vertan hat. Statt zwei Jahre bekam der SD-Slot somit halt nur zwei Monate. Handkehrum stellt Google hunderte Entwickler an, die als Einstellungsvoraussetzung über einen Doktortitel verfügen müssen, zahlt denen 200'000 Franken Einstiegsgehalt und dann sind diese Leute offenbar allesamt zu dumm zum Scheissen. Das kann doch alles nicht wahr sein! Android 2017 ist schlimmer als Windows 95! In jedem Aspekt!

Leider gibt es aber auch keine Alternative zu Android. Die ganzen Hoffnungsträger sind bereits eingestampft (Maemo, FirefoxOS, Ubuntu Phone), kommen nicht in die Puschen (Jolla), liegen im Sterben (Windows, Blackberry) oder sind proprietär (Apple, Windows, Blackberry). Bei den iPhones kommt noch dazu, dass die von vorneherein ohne SD-Kartenslot daherkommen.

So langsam muss ich mir überlegen, nicht aus einem Raspberry Pi, einem UMTS-Stick und einem Batteriepack etwas selber zusammenzufummeln. Das macht dann wenigstens, was ich will und ist einfach reparierbar (wenn auch unhandlich, unpraktisch und unsexy). Oder ich muss mit Herrenhandtasche gefüllt mit dedizierten Geräten für jeden Zweck das Haus verlassen. Zumindest fällt dann in der Regel nur ein Drittel des Geräteparks (Musikplayer, Kamera, Telefon) auf's Mal aus.

Mir ist ein altes Samsung Galaxy S2 in die Hände gekommen, das für einen potentiellen Empfänger tauglich gemacht werden sollte. Bislang war bereits ein etwas in die Jahre (oder doch nur Monate?) gekommenes Cyanogenmod installiert. Aber Cyanogenmod ist tot, darum soll auf jeden Fall aktuellste Software installiert werden. Da kommt fast nur LineageOS in Frage (v.a. auch da ich damit gute Erfahrungen auf S3 und S5 gemacht habe). Da der Empfänger noch empfindlicher auf seine Privatsphäre achtet als ich, habe ich die Google-Apps weggelassen. Diese zu installieren benötigt aber nur einen weiteren Befehl und zwei Klicks mehr in der Recovery.

Leider war die Installation nicht ganz einfach, da die /system-Partition erstens nur 500MB gross ist (das ist zu klein, LineageOS verlangt mindestens 600MB), zweitens einen Defekt hat und drittens alle im Internet gefundenen Anleitungen zur Installation und Repartitionierung falsch sind, insbesondere die offizielle Anleitung von LineageOS. Ausserdem sind die meisten Anleitungen von Windows-Schafen geschrieben und nutzen Odin, während mir unter Linux Heimdall zur Verfügung steht.

Als Voraussetzung für diese Anleitung setze ich voraus, dass der Leser mit TWRP bereits vertraut ist. Ausserdem gilt ganz klar: Anwendung auf eigene Gefahr!

Beim i9100 sind ein paar Spezialitäten zu beachten, so ist das Recovery-Image in das Kernel-Image integriert.

So hat's bei mir funktioniert:
Erst sichergehen, dass auf dem Computer die aktuellsten Versionen von heimdall und adb installiert sind.
Download von PIT-Dateien (eine Art Partitionstabelle für Samsung-Geräte) von hier
Download von TWRP (Custom Recovery) von hier
Download des aktuellsten LineageOS-Build von hier
Ggf Download des su-addons und/oder gapps, wenn benötigt.
Aus lineage-14.1-*-nightly-i9100-signed.zip muss die Datei boot.img extrahiert werden.
Aus Pit_files.rar muss die gewünschte PIT-Datei extrahiert werden, ich habe I91001GB_4GB.pit (1GB /system, 4GB /data) verwendet.

Boot des Telefons in den Download-Modus mittels VolDown-Home-Power (Bestätigen mit VolUp). Anschliessend das USB-Kabel anschliessen.
Upload des neuen PIT-Files und flashen der Recovery mittels:
heimdall flash --repartition --pit I91001GB_4GB.pit --RECOVERY twrp-3.1.0-0-i9100.img --KERNEL boot.img --no-reboot

Danach das Telefon ausschalten, das USB-Kabel ausziehen, kurz die Batterie entfernen (ansonsten liess es sich bei mir nicht wieder booten), Batterie wieder einfügen.
Start des Telefons in den Recovery-Modus mittels VolUp-Home-Power
TWRP sollte nun starten. In TWRP den Menüpunkt "Wipe" -> "Advanced Wipe" -> "System" -> "Repair or Change File System" -> "Resize File System". Bei Erfolg auf "back" klicken und in der Übersicht auf "Change File System" -> "ext4". In der Übersicht wird die Dateisystemgrösse falsch angezeigt, evtl sogar als 0 Byte. Dies ignorieren. Nach erfolgter Reformatierung auf "back" klicken. In der Übersicht sollte jetzt korrekt 1007MB als Dateisystemgrösse angezeigt werden. Dasselbe Spiel für "Data" und "Internal Storage" wiederholen. Es können dabei viele rote Fehler angezeigt werden, dass Partitionen nicht eingebunden werden können. Dies kann (hier) ignoriert werden.
Nun das Telefon wieder ausschalten, Batterie raus und wieder rein, und erneut in den Recovery-Modus booten.
in TWRP erneut auf "Wipe" -> "Advanced Wipe" und einen gleichzeitigen Wipe von Dalvik, Cache, System, Data und Internal Storage durchführen. Wenn keine roten Fehlermeldungen erscheinen, kann der Flash-Vorgang beginnen. Ansonsten muss so lange mit der Reformatierung herumgespielt werden, bis es klappt.

Nun das USB-Kabel wieder anschliessen und mittels adb die zu installierenden zip-Dateien hochladen:
adb push lineage-14.1-*-nightly-i9100-signed.zip /sdcard0/
Wichtig! Der interne Speicher heisst /sdcard0/, nicht /sdcard/, wie in vielen Anleitungen behauptet!

In TWRP nun auf Install gehen und die zip-Dateien gemäss handelsüblicher Anleitungen flashen. That's it. Uff. Ja, ist kompliziert und viel unnötiger Aufwand.

Update: Ein Leser weist mich auf diese hervorragende Anleitung hin... für Windows

Update: Ein weiterer Leser gibt noch zwei Tipps mit:
1. Wenn es mit dem Download der PIT-Datei nicht funktioniert, anderes USB-Kabel, bzw. anderen USB Port benutzen. Den Tipp gab's an verschiedenen Stellen und hat mir geholfen.

2. Ich habe es dann ums verrecken nicht geschafft, per "adb" etwas auf's Handy zu schieben. Ich habe es dann letztendlich auf eine Micro-SD karte kopiert, die ins Handy gesteckt und von dort installiert.

Gestern hat das Unfairphone zwar nochmals ein Software-Update erhalten, das zwar an der Oberfläche kratzt (z.B. Bildschirmflackern behebt oder den sinnlosen Privacy Indicator angeblich endlich deaktivierbar macht), aber die richtigen Probleme (fehlende Konfigurationsmöglichkeiten, fehlender Privacy Guard, fehlende Unterstützung für Dateisysteme) natürlich nicht behebt. Aber das ist dennoch zu spät, denn heute hat mir der Pöstler Ersatz geliefert. Diesmal ein von im Vergleich zum Unfairphone nicht ganz so glücklichen Chinesen zusammengeklebtes Galaxy S5. Warum so ein altes Gerät? Nun, im Prinzip ist es dasselbe wie das Unfairphone, nur in irreparabel, leicht und ohne zweiten SIM-Slot. Ansonsten ist die Hardware ziemlich identisch. Und: Es gibt eine recht solide Unterstützung durch CyanogenMod!

Gemäss Anleitung ist die Installation so kinderleicht wie beim S3. Doch der Teufel liegt wie immer im Detail. Erst startet man das Gerät mittels VolDown-Home-Power im Download-Modus und installiert ein Recovery-Image:

heimdall flash --RECOVERY twrp-3.0.2-1-klte.img --no-reboot
Heimdall v1.4.0
[..]
ERROR: Failed to download PIT file!

Muh! Wäre ja zu schön, wenn es auch nur ein einziges Mal einfach wäre!

Also muss als erstes Heimdall auf die letzte Version von github aktualisiert werden. Wie bei all meinen technischen Einträgen wird Debian als Basis verwendet. Bevor nun irgend ein Troll meint, na klar, mit der Uralt-Version aus Debian ist das auch kein Wunder: den Spruch kann man sich hier sparen, da auch die letzte offiziell veröffentlichte Version von Heimdall (1.4.1) nicht ausreicht. Es muss zwingend die Version aus dem git-Repository sein!

aptitude install build-essential cmake libusb-1.0-0-dev qt5-default libgl1-mesa-glx libgl1-mesa-dev
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd bin

Nun kann erneut gemäss Anleitung versucht werden zu flashen:

./heimdall flash --RECOVERY /path/to/twrp-3.0.2-1-klte.img --no-reboot

D.h. man startet die Recovery mittels VolUp-Home-Power. Als kleinen Umweg habe ich mittels des gestarteten Recovery erst ein Backup erstellt und dieses mit ADB auf den Desktop-Computer kopiert:

adb pull /sdcard/TWRP TWRP

Danach kann man aber wirklich gemäss Anleitung weitermachen, ein möglichst minimales Google-Apps-Paket installieren und sich an einem relativ schlanken, funktionalen Telefon mit verstärktem Schutz der Privatsphäre erfreuen.

Und das Unfairphone? Wird wegen Nichtgebrauchs verkauft. Und das S3? Wird zur Bastelplattform umfunktioniert.

Schon vor meiner Rückkehr habe ich mir das Fairphone 2 bestellt und liefern lassen, damit ich endlich mein vier Jahre altes S3 ablösen kann, das trotz CyanogenMod und vielen Tricksereien beständig langsamer wird. Während es sich beim Fairphone zwar um eine gute Idee handelt, ist die Software so schlecht, dass ich es wohl bald ersetzen muss, wenn nicht schnellstmöglich Unterstützung durch beispielsweise CyanogenMod kommt.

Das Fairphone 2 besticht vor allem durch "faire" Produktion. Das heisst zum einen dass den Arbeitern in den Fertigungswerken Löhne bezahlt werden, die das Überleben ermöglichen. Zum anderen werden möglichst nur konfliktfrei abgebaute Rohstoffe eingesetzt, d.h. nicht solche, die brutale Diktatoren oder blutrünstige Rebellentruppen finanzieren. Und auch der Kunde soll nicht zu kurz kommen, das Gerät ist modular aufgebaut, leicht zu reparieren und soll über mehrere Jahre mit Ersatzteilen und Softwareupdates versorgt werden.

Die Hardware ist ziemlich einwandfrei. Zwar bezahlt man den Preis der guten Reparierbarkeit durch ein relativ dickes, schweres Gerät. Doch dafür ist es griffig und liegt ausgesprochen gut in der Hand. Bei Verwendung fühlt es sich schnell an, das Display ist scharf, flimmert aber leicht. Neben zwei vollwertigen MicroSIM-Slots gibt es einen zusätzlichen Slot für eine MicroSD-Karte, man muss sich also nicht wie bei den meisten DualSIM-Geräten zwischen zweiter SIM und mehr Datenspeicher entscheiden. Der Akku ist natürlich wechselbar, somit kann man das Gerät bei einem kompletten Freeze auf die harte Tour Neustarten statt mehrere Stunden zu warten, bis der Akku leer ist. Auch softwareseitig ist der erste Eindruck gut. Halbwegs aktuelles Android und kaum vorinstallierter unnützer Bloat. Doch damit hat es sich leider schon...

Die rückseitige Abdeckung lässt sich nur mit viel Gefummel entfernen und wieder aufsetzen. Fraglich, wie lange die hält, bevor sie ersetzt werden muss. Ausserdem sammelt sich sehr viel Staub in der Kante zwischen Abdeckung und Display.

Für die Kamera gibt es einen Hardware-Knopf auf der Seite. Durch Druck wird die Kamera-App gestartet... Leider nicht immer auf den ersten Druck Ist die Kamera-App gestartet, funktioniert der Knopf als Auslöser. Das ist cool, somit kann man das Gerät als sehr schnell einsatzbereite Kamera verwenden. Sind weitere Fotogelegenheiten absehbar, kann der Bildschirm einfach über den Power-Knopf aus- und wieder eingeschaltet werden, die Kamera ist sofort wieder verfügbar. Leider mangelt es der Kamera-App an Funktionalität, ein Panorama-Modus wäre schon noch was... Ausserdem ist die Bildqualität eher mässig. Das alte S3 macht die deutlich besseren Fotos.

GPS funktioniert leider nur im High-Precision-Mode richtig. Dieser braucht aber mehr Strom und überträgt Standortdaten an Google. Im Device-Only-Mode dauert es mehrere Stunden, bis endlich die Position bestimmt werden kann. Das ist unbrauchbar.

SD-Karten werden nur erkannt, wenn sie mit dem uralten und nur mässig stabilen FAT32 formatiert wurden. Weder das Monopolisten-Dateisystem ExFAT noch freie Systeme wie ext4 sind unterstützt.

Bluetooth Pairing ist fast unmöglich, da paarungsbereite Geräte in aller Regel nicht gefunden werden.

Irgendwie hatte ich im Hinterkopf, dass eines der Ziele von Fairphone (erste Version) auch war, dass der Benutzer damit machen können soll, was er will. Das heisst auch, dass er relativ leicht und auf offiziell abgesegnetem Weg den root-Modus aktivieren kann. Nun, beim Fairphone 2 ist davon nicht viel vorhanden. Man muss modifizierte Images aus dubiosen Quellen flashen und auch sonst ein gewaltiges Gebastel vornehmen (siehe hier). Das ist ein schlechter Witz.

Schlimm wird es bei den Einstellmöglichkeiten von Android. Wenn man CyanogenMod mit seinen erschlagenden Möglichkeiten der Grob- und Feinkonfiguration kennt, fühlt man sich beim Fairphone wie ein Apple- oder Gnome-Jünger mit bescheuerten Voreinstellungen, die nicht änderbar sind. Zumindest den Wifi-Tethering-Button hätte ich schon gerne in den Quick-Toggles...

Aber so richtig schmerzhaft ist das Fehlen des Privacy Guard - wohl das Killerfeature von CyanogenMod. Damit lassen sich die Berechtigungen von Apps einschränken, ohne dass die Funktionalität der App ernsthaft beeinträchtigt wird. Somit kann man notorischen Privatsphäre-Killern beispielsweise den Zugriff auf das Adressbuch verweigern. Update: Stattdessen liefert Fairphone eine "Privacy Impact" Anzeige mit. Beim ersten Start einer App wird angezeigt, welchen Einfluss die App auf die Privatsphäre haben kann. Das ist total nervig und überflüssig, denn diese Information erhalte ich schon im Play-Store, wenn ich eine App installiere. Ausserdem kann ich mir nur anzeigen lassen, dass meine Privatsphäre verletzt wird, aktiv dagegen vorgehen wie beim Privacy Guard ist nicht möglich. Das Feature ist im Prinzip zwar deaktivierbar, doch wenn man das tut, funktionieren die meisten Apps nicht mehr richtig. Völlig gaga!

Doch all diese Problemchen sind ja nicht so tragisch, da man immerhin ein Gerät bekommt, das im Prinzip macht, wofür man es eigentlich erworben hat, oder? Nein! Tut es nicht! Denn es stürzt sehr häufig ab und bootet spontan neu. Oder das Netzwerk hängt sich auf, Internetzugriff wird nur durch einen manuellen Neustart wieder ermöglicht.

Und dann kommt der Todesstoss: Viele Apps funktionieren einfach nicht richtig! Eingabeformulare werden nicht ausgewertet oder falsch angezeigt. In CSipSimple können keine neuen Konten hinzugefügt werden, da der "Add Account" Button nicht auf Eingabe reagiert. In der Mobility App kann kein Standort ausgewählt und somit auch keine Reservation getätigt werden... Ich kann mir nicht vorstellen, dass dies generell an Android liegt - vermutlich ist die von Fairphone verwendete Grafikbibliothek einfach ein Bruch. Update: Die Probleme konnte ich beheben, indem ich das obsolete "Privacy Impact" wieder aktiviert habe, siehe hier.

Was also soll ich noch weiter mit diesem Schrottdings? Die produktive Nutzung ist mir kaum möglich, wenn das Gerät so unzuverlässig ist. Dem vielen Geld und den hohen Erwartungen wird das Gerät auf Anwenderseite so einfach nicht gerecht.

Letztes Wochenende hatte ich das Vergnügen, eine Fortinet-Installation zu konfigurieren. Das sind nicht ganz günstige Firewalls, die sich einen professionellen Anstrich geben. Dann ist ja alles easy, oder? Bislang hatte ich noch keine Erfahrung mit den Geräten und somit zum ersten mal welche von nahem gesehen.

• Alle paar Minuten (in einem zufälligen, willkürlichen Interval) wird man aus dem Webinterface automatisch ausgeloggt. Nicht gespeicherte Einstellungen gehen dabei verloren. Besonders toll, wenn das mitten in einem etwas längeren Assistenten passiert und man mehrfach von vorne anfangen darf.
• Die Geräte wären ja echt ausführlich dokumentiert. Leider verweist Google konsequent auf veraltete Dokumentation unter docs-legacy.fortinet.com und die Links sind nicht einfach zu docs.fortinet.com abänderbar... SEO, anyone?
• Die Doku besteht oft aus schönen Schritt-für-Schritt Anleitungen. Z.B. klicke auf den Menüpunkt "Router"... wait... das Gerät hier hat keinen Menüpunkt Routing... - oder klicke auf System -> Network -> Routing, dort auf New Item und fülle Feld X, Y, Z folgendermassen aus... nur dass der Assistent unter New Item die Felder X, Y und Z nicht bietet. aaaargh!
• Die Geräte müssen beim Hersteller registriert werden, um z.B. Firmware-Updates zu erhalten. Auch nach scheinbar erfolgreicher Registrierung motzt das Gerät, dass die Registrierung nicht vollständig sei.
• Auf einem der Geräte hat das dann auch dazu geführt, dass OTA-Firmware-Updates nicht möglich sind. Mann muss das Image also mühsam von Hand auf der Website des Herstellers suchen, anhand der kryptischen Dateibezeichnung das richtige erraten und ins Gerät hochladen.
• Somit haben wir zwei Geräte, beide mit der gleichen Firmware-Version und der gleichen Grundkonfiguration. Nun lassen wir auf beiden den gleichen Assistenten laufen und tragen die gleichen Werte ein (logischerweise sind die IP-Adressen jeweils abweichend, aber ansonsten...). Das Ergebnis: Man erhält völlig andere Resultatansichten.
• Es gibt eine USB-Konsole, worüber man die Geräte auch mit einer bequemen App für Desktop-Windows, OSX, Android und iOS konfigurieren und überwachen kann. Und ähem, hüstel, räusper... wo ist der Linux-Support?

Das sind alles Dummheiten, die ich bei einem Gerät, das 500 Franken aufwärts in der blanken Ausführung ohne Extras ausgesprochen ärgerlich finde. Das grundsätzlich kostenlose pfSense macht sowas nicht. Aber hey, wie sagt der Manager so schön: was nix kostet...

Handkehrum: Wenn die Dinger mal eingerichtet sind, scheinen sie ihren Zweck zu erfüllen. Immerhin. In der Grundkonfiguration scheinen sie auch standardmässig auf hohe Sicherheit eingstellt zu sein (d.h. es funktioniert zwar erstmal nichts, dafür funktioniert aber auch nichts, wovon man nichts weiss). Und mit dem Upgrade des OS auf Version 5.2 hat sich enorm viel an der Benutzerfreundlichkeit getan. Sonst wäre obige Liste noch viel länger.

Bis vor kurzem dachte ich, dass Infrarot an sich eine tote Datenübertragungstechnologie der Technikantike sei. Seit PDAs durch Smartphones ersetzt wurden und für die drahtlose Übertragung generell Bluetooth oder das omnipräsente WLAN genutzt wurden, welche den Vorteil haben, dass keine direkte, ungestörte Sichtverbindung bestehen muss, sind infrarotfähige Geräte eher selten geworden. Witzigerweise unterstützen die neusten Samsung-Telefone wieder Infrarot, mein altes S3 tut dies jedoch nicht.

Doch dann habe ich meinen ersten Tauchcomputer gekauft. Dieser war Teil eines preisgünstigen Komplettpakets inkl. Regulator. Wichtiges Kriterium war die Unterstützung durch Subsurface, damit ich die Tauchgänge auch mit meinen Linux-Computern auswerten kann. In der Tat steht das Gerät auf der Kompatibilitätsliste. Daher habe ich da auch gar nicht länger über das Übertragungsprotokoll informiert und sofort eingekauft.

Kaum angekommen wurde das Gerät ausgepackt und oh! Kein USB-Kabel mit dabei? mmmh, wie überträgt es dann? Oho, das Handbuch besagt Infrarot!? Was nun?

Nach kurzer Suche habe ich in meinem Hardware-Fundus ein altes IrDA-USB-Dongle wiedergefunden. Dies lag 10 Jahre lang unbenutzt umher, da es nicht durch lirc, die Linux-Software für Infrarot-Fernsteuerungen unterstützt wird. Dieses also auf Verdacht in den PC eingesteckt, den Tauchcomputer mit der Infrarot-Schnittstelle in Sichtweite hingelegt, Subsurface gestartet und den korrekten Tauchcomputer eingestellt. Sehr positiv: Subsurface stellt automatisch die korrekte serielle Schnittstelle (/dev/ttyS3) ein. Dann noch in Subsurface auf den "Importieren"-Knopf gedrückt und... der Tauchcomputer piept und Subsurface zeigt einen Fortschrittsbalken an. DAS ist doch mal ein positives Zeichen.

Wenn der Import nicht funktioniert, müssen folgende zwei Dinge geprüft werden: Erstens muss der Benutzer Mitglied in der Gruppe "dialout" sein. Zweitens muss unter Debian das Paket irda-utils installiert sein.

Doch wieso funktioniert mein IrDA-Adapter nicht mit lirc? Nun, für Fernbedienungen muss ein weiteres Protokoll, CIR, unterstützt werden. Mein Adapter vom Typ mcs7780 beherrscht aber wie fast alle USB-Adapter nur SIR, MIR und FIR und kann im Gegensatz zu seriellen Adaptern auch nur schwerlich manipuliert werden.

Welcher Adapter sollte nun gekauft werden? Das hängt natürlich primär vom Tauchcomputer ab, und welche Transfermodi dieser unterstützt. Leider schweigt sich der Hersteller in meinem Fall diskret aus (Nachtrag: Im Computer selbst kann der Tranfermodus zwischen Lo und Hi umgestellt werden - somit dürften SIR und FIR unterstützt sein). Generell scheinen die Adapter im Handel selten geworden zu sein und die Modellvielfalt ist eher gering. Gut verfügbar sind die Modelle von Polar für deren Uhren. Diese sind aber meiner Meinung nach unverhältnismässig teuer und unterstützen u.U. nur SIR. Generell sollte man daher immer zu einem Modell greifen, das alle drei gängigen Modi unterstützt.
Welche Modelle von Linux unterstützt werden, ist ebenfalls eher schwierig in Erfahrung zu bringen. Die verfügbaren Dokumentationen sind uralt und stammen teilweise aus Zeiten von Kernel 2.4. Und natürlich halten die Hersteller der Dongles in ihren Werbebroschüren oft geheim, welche Chips sie verbauen.

Fazit (tl;dr): Aus meiner Erfahrung ist klar, dass der Moschip msc7780 von Linux bestens unterstützt wird und für Datenübertragungen mit den meisten Infrarot-Endgeräten funktionieren sollte.

Nachdem mein tragbarer Computer mit eingeschränkter Telefoniefähigkeit und Staatsüberwachung immer langsamer geworden ist, habe ich vor ein paar Monaten endlich einen kompletten Reset durchgeführt und die originale Bloatware durch das relativ schlanke CyanogenMod (inkl Google Apps Paket) ersetzt. Das hat sich absolut gelohnt, das Gerät flitzt regelrecht und konnte dadurch seine Lebens- bzw Gebrauchsspanne nochmals deutlich verlängern.

In Benutzung ist hier ein Samsung Galaxy S3 i9300. Die Installation verlief problemlos und strikte gemäss Anleitung von einer Debian 7 (amd64) Maschine aus.

Vorteile:

• Sehr flotte Bedienoberfläche
• Brandaktuelles Android 4.4 Kitkat, welches ja gemäss Samsung nicht auf dem Gerät laufen sollte.
• Monatliche (Sicherheits)Updates
• Viel weniger installierter, unnützer Bloatmüll. Lediglich von Google ist noch Bloat drauf. Google Maps ist leider derzeit noch eine ziemliche Killerapp, ansonsten wäre ein komplett freies System mit z.B. f-droid als Appstore sicher denkbar. Mal auf Nokias Here-Maps warten
• Reduzierter Speicherverbrauch (was wohl auch zur höheren Geschwindigkeit beiträgt)
• Im Allgemeinen eine längere Akkulaufzeit - die Laufzeit scheint mir aber etwas stärker zu schwanken als mit der Originalfirmware. Das ist aber eine subjektive Empfindung ohne wissenschaftliche Prüfung
• Tiefere Latenz und Jitter im WLAN
• Unterstützung für Linux-Dateisysteme wie ext4. Sehr schön bei USB-Datenträgern und grossen SD-Karten

Eins muss man Samsung allerdings lassen, grad die Samsung eigenen Apps sowie viele Touchwhiz-Funktionen waren ausgesprochen durchdacht, hilfreich und ergonomisch, so dass der Ersatz doch etwas Zeit und den Test diverser Apps benötigt hat:

• Bildbetrachter: QuickPic - das hatte ich schon mit der Originalfirmware im Einsatz
• Kamera: Focal Beta - leider friert die Kamera gelegentlich ein oder die App tut zwar so, als ob sie Bilder machen würde, tut dies aber nicht. In jedem Fall hilft nur ein kompletter Neustart des Geräts. Ob das an Focal oder CyanogenMod liegt, habe ich bislang nicht herausgefunden. Die aktuelle Version der CM-Standard-Fotografie-App macht unterdessen einen deutlich besseren Eindruck als vor ein paar Monaten, so dass ich hier womöglich wechseln werde.
• Bildschirm aktiv halten, wenn in Benutzung: Smart Stay + Die App erfüllt an sich den Zweck, wofür sie installiert wurde, verursacht aber einen gewaltigen und nicht dokumentierten Datenverkehr. Meine "Zweckselfies" möchte ich allerdings nicht in den Händen der NSA oder des Entwicklers wissen, weshalb die App mittels Firewall ruhiggestellt werden sollte.
• Anrufe Ruhigstellen durch Umdrehen: Flip - Silent
• Spezielle SMS-Klingeltöne für einzelne Kontakte: Ringo
• Ersatz für das SPlanner Kalenderwidget: SolCalendar

Natürlich ist auch mit CyanogenMod nicht alles Milch und Honig, in Sachen Hardwareunterstützung funktioniert z.B. die Bildausgabe auf externe Monitore per HDMI-Adapter nicht mehr. Das ist allerdings ein Feature, das ich eh kaum je gebraucht habe, somit kann ich damit leben. Etwas unzufrieden bin ich auch mit der SMS-App, welche leider nicht anzeigt, wie viele Zeichen schon getippt wurden. Auch schön wäre es, wenn die SMS-App gleich die Funktionalität von Ringo integrieren würde. Ärgerlich: Der Empfang von MMS scheint nicht zu funktionieren.

Als neues Spielzeug habe ich mir eine per Netzwerk schaltbare Steckerleiste besorgt, um abgestürzten Raspberries und ähnlichen Geräten auch aus der Ferne einen Neustart zu ermöglichen. Für die Steuerung gibt es ein Webinterface, eine proprietäre Software für ein proprietäres Betriebssystem und eine Handy-App, wofür das Gerät zum Server des Herstellers verbinden muss. Für eine Automatisierungslösung auf der Linux-Konsole muss daher etwas Kreativität und ein paar Zeilen Shellcode her. "Glücklicherweise" ist das Webinterface mit der ganz heissen Nadel gestrickt und Security als überflüssige Geldverschwendung abgetan worden, daher ist das Skript recht simpel ausgefallen:

#!/bin/bash
HOST="192.168.0.x"
PASSWORD="foo"
OUTLET=$1
STATE=$2
curl -sd "pw=$PASSWORD" http://$HOST/login.html | fgrep -q Status
if [ $? -eq 0 ]; then
curl -sd "ctl$OUTLET=$STATE" http://$HOST/status.html | fgrep -q Status
fi
curl -s http://$HOST/login.html | fgrep -q password

Das Skript legt man z.B. unter /usr/local/bin/gembird.sh ab und gibt ihm Ausführungsrechte (chmod +x). Anschliessend lässt es sich aufrufen via gembird.sh dosennummer neuer_zustand, also z.B. gembird.sh 4 0 um die vierte Dose auszuschalten.

Die Hauptarbeit des Webinterface-reverse-Engineerings hat zum Glück schon ein Kritiker auf Amazon übernommen, da der offizielle Herstellersupport nicht sehr hilfreich war. Merke: nächstes Mal die Frage stellen in der Art "ich möchte in Windows unter Cygwin..."

Erst den USB-Stick präparieren:

dd if=/dev/zero of=/dev/sdb bs=512 count=1
mkfs.vfat -F32 -I /dev/sdb
syslinux /dev/sdb
mount /dev/sdb /mnt/temp
cd /mnt/temp
tar -jxf /tmp/apu_tinycore.tar.bz2

Danach das APU vom USB-Stick booten und das BIOS updaten:

cd /mnt/sda
flashrom -w apu140405.rom
poweroff

Als ich meinen Desktop und Server zusammenstellte, hatte ich bewusst für beide Geräte das gleiche Mainboard verwendet. Somit muss ich alle Mainboard-bedingten Probleme nur einmal lösen. Soweit hat das alles ganz gut funktioniert, aber unterdessen hat der Hersteller ein paar BIOS-Updates herausgegeben, welche Performance und Stabilität (nicht, dass das ein Problem wäre) verbessern würden. Na dann, spielen wir die mal ein. Da das Board von flashrom unterstützt wird, geht das total simpel direkt von Linux aus.

Erst das alte BIOS sichern:

flashrom -r old-bios.rom

Dann das neue BIOS flashen:

flashrom -w new-bios-image.rom

Vor einigen Wochen war erst der Desktop fällig. Nach dem Neustart durfte ich feststellen, dass die MAC-Adresse der Netzwerkkarte sich geändert hatte. Das ist halb so wild, da wird die /etc/udev/rules.d/70-persistent-net.rules gelöscht oder modifiziert und anschliessend neu gestartet.

Heute war der Server dran. BIOS geflasht, die udev-Regeln gelöscht, neu gestartet, alles bestens. Per SSH versucht anzumelden. Geht nicht. hmmm. Mal die Netzwerkkarten geprüft. Alles bestens. Ping von Server und Desktop zu jedem anderen Host klappt, nur nicht untereinander. dmesg geprüft:

br0: received packet on eth0 with own address as source address

Nochmals genau hingeschaut und ifconfig eth0 auf beiden Maschinen eingetippt und die MAC-Adresse genauer angeschaut. Un-glaub-lich! Identisch auf beiden Kisten. Die Deppen bei Asus haben es doch tatsächlich fertiggebracht, ein BIOS-Image zu verteilen, in welchem die MAC-Adresse für die onboard-Netzwerkkarte hartcodiert ist! Ja ist es denn wirklich so viel zuviel verlangt, wenigstens ein Mal mit Profis (oder zumindest nicht komplett inkompeteten Amateuren) zu arbeiten???

Würgaround:

ifconfig eth0 hw ether 00:e0:12:34:56:77

Unter Debian macht man dies permanent durch einen Eintrag in der /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
hwaddress ether 00:e0:12:34:56:77

Nicht mehr ganz so trivial wird das, wenn nun eth0 gebridged wird, damit KVM oder XEN Virtual Machines das Netzwerk mitbenutzen können. In diesem Fall ist eth0 nicht in der interfaces konfiguriert (bzw auf manual gesetzt), so dass jegliche Einträge aus der Sektion nicht gelesen werden. Hier muss der Konfiguration von br0 ein pre-up Befehl mitgegeben werden:

iface eth0 inet manual

auto br0
iface br0 inet static
pre-up ifconfig eth0 hw ether 00:e0:12:34:56:77
bridge_ports eth0
address 192.168.0.XXX
netmask 255.255.255.0
gateway 192.168.0.XXX

Der Raspberry Pi ist aufgrund von Preis, Ausstattung und Grösse prädestiniert für kleinere embedded-Konfigurationen im Netzwerk. Leider scheint in der Standardkonfiguration der Netzwerkdurchsatz trotz 100Mbit-Adapter nicht komplett ausgereizt zu werden. Bei meinen Tests mit NFS, Bridging-Durchsatz (mit zusätzlicher USB-Netzwerkkarte) oder ipperf bin ich auf maximal ca 50Mbit/s gekommen. Etwas dürftig. Aber dafür gibt es eine Lösung: übertakten! Die neueren Firmware-Versionen und raspi_config lassen es zu, dass der Raspberry ohne Garantieverlust übertaktet werden darf. Allerdings ist der Nachteil weiterhin, dass der Stromverbrauch steigt, auch wenn der Raspi grad nicht arbeiten muss. Auch dem kann abhilfe geschaffen werden durch dynamisches Übertakten bzw Nutzung von Powermanagement wie man es aus der x86-Welt in Notebooks und Desktops kennt. Hierfür habe ich folgende Konfiguration verwendet:

Für dynamische Taktung wird eine Untergrenze und ein Höchsttakt in der /boot/config.txt definiert. Ich war da etwas kreativ und habe den Ruhetakt etwas heruntergesetzt, ebenso RAM und die kaum genutzte GPU etwas gedrosselt:

arm_freq_min = 500
arm_freq = 900
core_freq_min = 200
core_freq = 300
gpu_freq_min=200
sdram_freq_min = 350
sdram_freq = 450
over_voltage = [-2,2]

Mehr Einstellungsmöglichkeiten und die Standardwerte zu den einzelnen Parametern gibt es bei elinux.org.

Um nun die dynamische CPU-Taktung per Powermanagement zu aktivieren, muss der entsprechende Governor geladen werden:

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Um diese Einstellung permanent zu machen, hält man sie am Einfachsten in der Datei /etc/rc.local fest. Eine Möglichkeit, den Governor per Kernel-Parameter zu setzen, so dass der Bootprozess vom höheren Maximaltakt profitiert, konnte ich bislang nicht ausfindig machen.

Mit dieser Einstellung wird der Netzwerkdurchsatz auf 96Mbit/s gesteigert (gem ipperf), was dem theoretischen Maximum von 100Mbit/s doch schon sehr nahe kommt.

Der WR841N v8 von TP-Link ist eigentlich gar kein schlechter Router für seinen Preis. Der Billigstheimer kommt mit ganz tauglicher Hardware daher und die Software ist eigentlich gar nicht sooo schlecht. Allerdings sind die Latenzen doch eher hoch und der Jitter untragbar. Zum Glück unterstützt die neuste Version von OpenWRT auch die neuste Revision des Geräts. Also auf, frische Firmware aufspielen. Nun gibt es zwei Images mit unterschiedlichen Dateisystemen, jffs2 und squashfs. Gemäss der Beschreibung schien mir jffs2 doch die bessere Wahl zu sein. Grosser Fehler, das jffs2-Image bootet nämlich nicht sauber, das Resultat ist ein unbrauchbarer Ziegelstein.

Was tun? Nun, man kann verzweifeln und in anbetracht des lächerlichen Preises ein Ersatzgerät bestellen oder sich vom Ehrgeiz packen lassen und den unbrick-Prozess starten. Dazu mussten als erstes die PINs in den Serial Header gelötet werden. Die Löcher sind praktischerweise schon da, aber die PINs waren wohl zu teuer. Na gut, Lötkolben her und los.

Danach wird das eigentlich für den Raspberry Pi angeschaffte serielle Konsolenkabel angesteckt. Das PIN-Layout ist identisch mit v7, nur um 90° verdreht. D.h. der alleinstehende PIN ist weiterhin TX. Entsprechend wird das Kabel nun angesteckt und mit einem PC verbunden. Da die Versorgung nun über den seriellen Port erfolgt, startet der Router auch sofort und per minicom lässt sich der Bootprozess mitverfolgen:

minicom --device /dev/ttyUSB0 -b 115200

Scheinbar hängt der Bootprozess beim laden der USB-Module (ohci_hcd). Das lässt sich verhindern, indem man in den Failsafe-Mode bootet. Dazu muss man, wenn der Prozess für ca 1s steht und die entsprechende Meldung anzeigt, rasch f[enter] eintippen. Schon erhält man eine root-Konsole und kann mit debugging loslegen.

Tatsächlich löste sich das Problem nun recht simpel. eth0 war unter 192.168.1.1 verfügbar, allerdings war eth0 der blaue WAN-Port, keiner der gelben LAN-Ports. Ausserdem schien der DHCP-Server nicht in Betrieb zu sein, so dass dem angeschlossenen Computer manuell eine IP-Adresse vergeben werden musste:

ifconfig eth0 192.168.1.2 netmask 255.255.255.0

. Anschliessend musste auf dem Router noch die Weboberfläche gestartet werden:

/etc/init.d/uhttpd start

und schon konnte bequem per Klickibunti das korrekte Firmware-Image (squashfs) aufgespielt werden.

Das Resultat: ein superflotter WLAN-Router mit relativ tiefen und stabilen Latenzen - zum Spottpreis.

Und vermutlich wäre der Lötkolben gar nicht mal nötig gewesen. Scheinbar kommt man auch in den Failsafe-Mode, indem man direkt nach dem Einschalten den Reset-Knopf drückt. Konsolenzugriff erhält man in diesem Fall per Telnet.

Neulich hatte ich eine Diskussion über Open Source, Closed Source und Sicherheit. Mein Standpunkt war, dass ich mir sicher nicht proprietäre Software wie Dropbox oder Wuala installieren möchte. Natürlich ist Sicherheit hier mit ein Argument. Allerdings nicht nur die Sicherheit davor, dass kein Schadcode in der Software enthalten ist. Grad bei grösseren OpenSource-Projekten kann auch das nicht zu 100% ausgeschlossen werden. Grad die gewaltigen Codemengen, welche einige Firmen in Form von Treibern beitragen, kann kaum sinnvoll extern reviewed werden, da für ein komplettes Verständnis auch die Hardware-Spezifikation bekannt sein muss.

Es geht mir eher um eine andere Form von Sicherheit: Die Sicherheit, dass ich die Software auch morgen noch einsetzen kann. Denn proprietäre Software hat hier schon immer zu Problemen geführt. Entweder ist der Hersteller überhaupt nicht (mehr) willig, gewisse Plattformen zu unterstützen, oder er ist bei der Unterstützung neuer Plattformen einfach viel zu langsam. Letztendlich kann ich 90% allen Ärgers, den ich unter Linux je hatte, auf das 1% proprietäre Software schieben, den ich im Einsatz habe oder hatte.

Hier nur mal ein paar Beispiele aus meiner Erfahrung:

• VMWare Server (vor vielen Jahren): Nach dem Kernelupdate (Bugfix-Release) lassen sich die Module ums verrecken nicht mehr kompilieren.


• Adobe Flash Player: Erinnert sich noch wer an die Zeiten, als 64bit unter x86 noch neumodischer Schnickschnack war? Da hatte man die Wahl, entweder einen 32bit-Browser ins System reinzuwürgen, den semiproprietären nspluginswrapper zu verwenden, um das 32bit-Flashplugin unter 64bit-Browsern zu nutzen, oder aber eine der nicht funktionierenden freien Flash-Alternativen zu installieren. Oder einfach alternativ jahrelang auf Flash verzichten. Oh, Adobe hat ja neulich auch beschlossen, dass Flash für amd64 in Zukunft gar nicht mehr weiterentwickelt wird.


• Skype: Bis es endlich die offiziellen "64bit"-Pakete gab, konnte man die Software nur unter kompletter Verhunzung der Paketverwaltung ins System würgen. Und dann noch dieses neumodische Audiotreiberzeugs namens ALSA, lass mal noch ein paar Jahre beim obsoleten OSS bleiben... aber hey, das grauenhafte PulsAudio-Zeugs, das ist so schlecht, das unterstützen wir sofort und exklusiv.


• PowerVR Grafiktreiber (für die gute, alte KyroII): nett, dieses Kernel 2.6 Zeugs. Aber einen (instabilen) Treiber gibt's nur für Kernel 2.4. Wer's neuer will, der kann ja den VESA-Treiber nehmen. Doku für die freie Treiberentwicklung? bwahahaha, der war gut!


• nVidia-Grafiktreiber: Trotz Linus' Stinkefinger ja die Vorzeigefirma unter den proprietären Treiberentwicklern: Oh, alte Hardware wird nicht mehr unterstützt. Ausser mit alten Treiberversionen, die keine neuen Kernel unterstützen. Oh, und dieses neumodische KMS-Zeugs mit älterer Hardware... nun, hübsche Konsole, so mit extremer Verzerrung und nicht mehr leserbaren Bootmeldungen...


• AMD-Grafiktreiber: Lass mal den neusten AMD-Treiber auf einem 6 Jahre alten Kernel kompilieren... oh geht nicht, Kernel ist zu neu... Dazu hab ich mich ja schon mehrfach ausgelassen. Ganz davon abgesehen, dass die letzte Treiberversion für meine Hardware der 12.04 ist. Da kann ich nur hoffen, dass bis ich den Umstieg auf Debian 8 ins Auge fasse, der freie radeon-Treiber was taugt. Grad im Bereich Multimonitor.


• Druckertreiber für non-Postscript Drucker: Funktionieren nur mit sehr exotischen Distributionen, haben komische Abhängigkeiten, und natürlich nur für 32bit x86 Systeme.


• Wine und Windows-Spiele: Guter Witz. Ich hab da kaum je was zum laufen gekriegt. Auch wenn Wine der Meinung war, das Spiel hätte Platin-Unterstützung (d.h. perfekt)

Aber auch Hardware ist mühsam, sobald sie nicht über ausreichend freie Dokumentation verfügt:

• Noch einmal AMD und nVidia: Die freien Treiber waren jahrelang gar nicht brauchbar, unterdessen geht wenigstens so langsam mal das grundlegende.


• Windows-Only GDI Drucker: aaaaaaaaaargh!


• Nokia-Telefone: Viel Spass beim Zugriff mit Gnokii. Vielleicht geht es. Wahrscheinlich nicht.


• Pogoplug: Die Pro-Platine (auch im spottbilligen Pogoplug Pink verwendet) verwendet ein proprietäres SoC, in dessen Dokumentation nur ein freier Entwickler unter NDA Einsicht hat. Die Konsequenz: Das Gerät läuft nur mit Arch Linux ARM und uralt-Kernel 2.6.31. Und die wichtigsten Treiber für viele USB-Geräte fehlen darin.

A propos Pogoplug: Der sowie z.B. der Raspberry Pi benutzen die ARM-Architektur. Über die Verwendung von Skype, Flash oder Dropbox nachzudenken, ist absolut müssig.

Die neueren Versionen von Gnokii (0.6.30 und neuer) bieten eine neue Verbindungsoption zu s40-Telefonen: Den Phonet-Treiber. Leider ist die Dokumentation im Gnokii-Wiki dazu sehr spärlich und auch sonst weiss das Internet nicht viel dazu. Jedoch ist er relativ gut im Source-Tarball des Gnokii-Projekts beschrieben. Die Source brauchte ich sowieso, um das aktuelle Gnokii für mein Debian Squeeze zu kompilieren.

Die Idee hinter diesem Treiber ist, dass die Nokia-Telefone sich als USB-Modem einbinden lassen und eine virtuelle Netzwerkschnittstelle erstellt wird. Um diese ansprechen zu können, müsste gnokii im Prinzip mit root-Rechten ausgeführt werden. Man kann das jedoch umgehen. Einerseits muss man der gnokii-Applikation etwas mehr Capabilities zugestehen, andererseits muss man dafür sorgen, dass die Schnittstelle automatisch gestartet wird, wenn man das Telefon an den PC anschliesst:

Gnokii Capabilities setzen (als root):

setcap cap_sys_admin,cap_net_raw=+ep $(which gnokii)
setcap cap_sys_admin,cap_net_raw=+ep $(which xgnokii)

Um die virtuelle usbpn-Schnittstelle automatisch zu starten, werden unter Debian/Ubuntu folgende drei Zeilen in der /etc/network/interfaces benötigt:

allow-hotplug usbpn0
iface usbpn0 inet manual
up ifconfig usbpn0 up

Nun muss noch die gnokii-Konfigurationsdatei unter ~/.config/gnokii/config erstellt werden:

[global]
port = usbpn0
connection = phonet
model = series40
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[logging]
[flags]

Leider hat mich das nicht ernsthaft weiter gebracht. Das Billigst-Telefon (Nokia C1) lässt weiterhin keinen Zugriff auf die SMS-Inbox zu. Telefonbuch auslesen und bearbeiten sowie zumindest SMS versenden klappt sowohl über den AT- wie auch den Phonet-Treiber problemlos.

Nachtrag vom 24.10.: mit Debian Wheezy lässt sich zumindest die Ordnerliste anzeigen, jedoch wird jeder Ordner als leer angezeigt. Das Speichern von SMS funktioniert. SMS lesen scheint aber nach wie vor nicht zu klappen.