Schlagwort: LineageOS

Congstar, VoLTE und ein Google Pixel der ersten Generation

· · 0 Kommentare

Technik kann frustrierend sein, vor allem, wenn die mehr oder minder geplante Obsoleszenz zuschlägt. Ein gutes Beispiel dafür ist VoLTE, eine neue Technik, deren Vorteil in einem schnelleren Gesprächsaufbau sowie dem Wegfallen des Netzwechsels auf 2G / 3G beim Telefonieren liegt.

Das Google Pixel der ersten Generation ist seit Android 7.1.1 VoLTE-fähig, Congstar hat VoLTE im Laufe des Jahres 2020 freigeschaltet, trotzdem fehlt im Einstellungsdialog die benötigte Option:

Der Status des Dienstes lässt sich mit Hilfe der Telefon-App überprüfen. Hierzu "*#*#4636#*#*" wählen, in der sich öffnenden Liste auf "Telefoninformation" tippen und über die drei Punkte in der rechten oberen Ecke den "IMS-Dienststatus" aufrufen.

Die Suche nach möglichen Ursachen und / oder Erklärungen führte ins Congstar Support Forum, wo ein Besitzer eines Google Pixel der ersten Generation erklärt:

Nun wissen wir dass einerseits das Gerät VoLTE hardwareseitig unterstützen muss, und zusätzlich in der Gerätekonfiguration hinterlegt sein muss, dass VoLTE speziell für den aktuellen Provider genutzt werden kann.
... in der CarrierConfig Stand Oktober 2019 (letztes Sicherheitsupdate für das Pixel) ist leider hinterlegt, dass Congstar kein VoLTE unterstützt. ... Nur wird unter anderem mein Google Pixel nie mehr ein Update von Google erhalten ... [Quelle]

Das Problem ist also, daß auch wenn Netz und Hardware VoLTE unterstützen, keine automatische Aushandlung erfolgt, sondern eine Konfigurationsdatei auf dem Gerät vorhanden sein muss, welche die Kombination aktiviert. Der Autor des Forenbeitrags weist noch auf die Möglichkeit hin, daß Congstar mittels einer speziellen App VoLTE auch für ältere Geräte freischalten könnte, aber die Diskussion führt leider zu keiner sinnvollen Rückmeldung des Congstar Supports.

Im Android-Hilfe Forum hat sich jemand im Thread "VoLTE/VoWiFi mit Congstar-SIM und Android 11" für das Pixel 2 mit dem Problem beschäftigt, da Google zwar eine Konfigurationsdatei ausliefert, in dieser aber leider VoLTE nicht aktiviert hat. Er kam zu einer einfachen Lösung: dem Pixel 2 die Konfigurationsdatei eines neueren Pixel-Modells unterzuschieben:

Wer Root-Rechte hat, kann das folgende Magisk-Modul installieren, um die congstar_de.pb vom Pixel 3 zu nutzen [Quelle]

Die Idee scheint sinnvoll und sollte auch mit einem Pixel 1 mit LineageOS 17.1 und installiertem Magisk funktionieren. Da ich gerne Zusammenhänge verstehe und ungern aus Foren heruntergeladene Dateien auf mein System loslasse, ging es ans Basteln.

Herunterladen und Entpacken eines Factory Images

Als erstes muß eine Konfigurationsdatei besorgt werden, welche die gewünschten Einstellungen enthält. Ich habe hierfür das aktuelle Pixel 3 Factory Image "11.0.0 (RQ1A.210205.004, Feb 2021)" verwendet, welches von der offiziellen "Factory Images for Nexus and Pixel Devices" heruntergeladen werden kann:

$ wget https://dl.google.com/dl/android/aosp/blueline-rq1a.210205.004-factory-3ab98ba8.zip

Das heruntergeladene ZIP wird entpackt, ebenso wie das darin enthaltene ZIP:

$ unzip blueline-rq1a.210205.004-factory-3ab98ba8.zip
$ cd blueline-rq1a.210205.004/
$ unzip image-blueline-rq1a.210205.004.zip

Die gesuchten Dateien befinden sich in der Datei "product.img". Um an sie heranzukommen, wird das im Android Sparse-Format vorliegende Image mit simg2img konvertiert und ins Dateisystem eingehängt:

$ simg2img product.img product.img.raw
$ mkdir product_image
$ sudo mount -o ro product.img.raw product_image/

Alle Einstellungen für die Provider liegen im Ordner "product_image/etc/CarrierSettings", von wo aus sie kopiert werden können. Danach wird der Ordner nicht mehr benötigt und kann ausgehängt werden.

$ sudo umount product_image/

Magisk-Modul

Das Magisk-Modul muß dem System lediglich eine Datei hinzufügen, alle optionalen Skripte können weggelassen werden. Die Struktur des Moduls kann der Dokumentation entnommen werden, lediglich beim Befüllen der Datei "module.prop" ist etwas Kreativität gefragt.

congstarvolte_pixel1.zip
│
├── META-INF
│   └── com
│       └── google
│           └── android
│               ├── update-binary      <--- Datei module_installer.sh
│               └── updater-script     <--- string "#MAGISK"
├── module.prop                        <--- gemäß Doku anlegen
├── system
│   └── product
│       └── etc
│           └── CarrierSettings
│               └── congstar_de.pb     <--- Datei aus dem Pixel3 Image

Nach der Installation des Moduls und vor dem zur Aktivierung notwendigen Neustart muß noch die Konfigurations-xml-Datei im Ordner "/data/user_de/0/com.android.phone/files" gelöscht werden, Congstar hat die Carrier-ID 2092.

Nach einem Neustart sollte dann auch die Ausgabe des IMS-Dienststatus passen:

Als kleine Stolperfalle wurde mit der neuen Konfigurationdatei der APN von "internet.telekom" auf "internet.v6.telekom" umgestellt. Falls es mit irgendeiner App hakt, kann manuell wieder zurückgestellt werden.


Update Google Pixel von LineageOS 16 auf 17.1

· · 0 Kommentare

Vor wenigen Tagen wurde LineageOS 17.1 veröffentlicht - Zeit auf die aktuelle Version zu wechseln und hierbei gleich neue Lineage Recovery auszuprobieren. Der in LineageOS eingebaute Updater erkennt zwar, daß eine neue Version vorliegt, kann das Update aber nicht manuell durchführen.

LineageOS

Die sehr kurz gehaltene Upgrade-Doku spart leider aus, daß man das Lineage Recovery nicht wie bisher für TWRP empfohlen mittels "fastboot boot ..." direkt starten kann, denn dann erscheint lediglich eine Fehlermeldung:

$ sudo fastboot boot lineage-17.1-20200418-recovery-sailfish.img
...
FAILED (remote: dtb not found)

Ein Blick in die Installations-Doku zeigt, daß die Lineage Recovery installiert werden soll:

$ fastboot flash boot lineage-17.1-20200418-recovery-sailfish.img

Anschließend kann die Recovery gestartet werden (Power & Volume down) und über die Menüpunkte "apply update" / "apply from adb" empfangsbereit gemacht werden. Die eigentliche Installation des Updates ist unspektakulär:

$ adb sideload lineage-17.1-20200418-nightly-sailfish-signed.zip

GApps (optional)

Die Dokumentation weist darauf hin, daß es wichtig ist, den Zustand bzgl. eventuell verwendeter GApps beizubehalten, d.h. wenn welche installiert waren, müssen sie vor dem ersten Start des Betriebssystems aktualisiert werden.

Hierzu wird die Recovery erneut gestartet und bereit zum Datenempfang gemacht, dann kann das Paket installiert werden.

$ adb sideload open_gapps-arm64-10.0-pico-20200418.zip

Root

Das bisher für LineageOS 16 angebotene "addonsu" ist aus technischen Gründen leider nicht mehr erhältlich

... our usual provided AddonSU zip to enable root access for the user is no longer feasible

weshalb auf Alternativen wie Magisk ausgewichen werden muss.

... if you want root for apps, flash magisk zip in recovery. Just don't flash it during initial lineage install, as it's known to cause bootloop if you do.

Wichtig ist, Magisk nicht zusammen mit LineageOS zu installieren, ob hier ein erneuter Start der Recovery reicht oder ein Systemstart erfolgen sollte, ist nicht ganz klar. Die Installation erfolgt analog zu LineageOS bzw. den GApps am sinnvollsten nach einem Systemstart.

$ adb sideload Magisk-v20.4.zip

Nacharbeiten

Nach der Installation kam von Magisk keine Aufforderung von AFWall+ zum Erhalt von Root-Rechten. Nach einem weiteren Reboot kam dann aber die erwartete Aufforderung.

Der Captive-Portal-Check lief trotz übernommener AFWall+-Einstellungen immer auf einen Verbindungsfehler, die Liste der Freigaben musste noch um "[1073] Network Stack, com.android.server.NetworkPermissionConfig" erweitert werden, ansonsten wurde dauerhaft das "X" beim Verbindungsstatus angezeigt und einige Apps haben erst gar nicht versucht, sich mit dem Internet zu verbinden.


Entrust IdentityGuard Mobile und LineageOS

· · 0 Kommentare

Auf den Versuch, Entrust IdentityGuard Mobile auf (m)einen Google Pixel mit aktuellem LineageOS 16 in Betrieb zu nehmen, hat die App nur mit einem

Manuelle Aktivierung wird auf einem ungesicherten Gerät nicht unterstützt

reagiert. Tatsächlich fördert die Suche auf der Entrust-Website die Info hervor, daß der Betrieb der App auf einem Custom Rom nicht möglich ist.

Entrust IdentityGuard mobile has detected that it is running on an unsecured device. Application exiting

The issue is that you have Jail broken (iPhone) Rooted (Android) or hacked/cracked your mobile device, you will not be able to install the soft token and will need to either install it on a different device (e.g. workstation or other mobile device) or switch to the eGrid Card.

Stattdessen läuft die App jetzt auf einem Nexus 4 unter Android 5.1.1mit Softwarestand Juli 2015, bestimmt ein riesiger Sicherheitsgewinn.


Samsung Galaxy Tab S2 mit LineageOS

· · 15 Kommentare

Auch wenn der Markt für Android Tablets auf den ersten Blick nach halbwegs Ausahl aussieht - spätestens beim Blick auf die Sicherheitsupdates kommt der Gedanke, daß es um diese nicht nur gefühlt nochmals eine ganze Ecke schlechter bestellt ist als bei Smartphones.

Denkt man gar darüber nach, ein alternatives Betriebssystem wie LineageOS einsetzen zu wollen, bleiben von den aktuell am Markt befindlichen Geräten nur noch wenige übrig. Als "Preis-Leistungssieger" entpuppt sich das Samsung Galaxy Tab S2, welches mit immer noch ausreichender Ausstattung als Neugerät erhältlich und für das offiziell LineageOS 16 verfügbar ist.

Wichtig ist, die richtige Version des Gerätes zu erwischen. Statt der Urversion des S2 von 2015 wird die aktualisierte Version von 2016 benötigt, in welcher der Samsung eigene Exynos-Prozessor durch einen Qualcomm Snapdragon ersetzt wurde. Wie das LineageOS Wiki verrät, handelt es sich hierbei um die Modellnummer SM-T813, Codename "gts210vewifi".

Im Wiki findet sich auch eine Installationsanleitung, welche sich im Vergleich zu z.B. den Google-eigenen Nexus-Geräten nicht einfach nachklicken lässt, sondern so manchen Stolperstein beinhaltet.

Heimdall

Während bei "normalen" Android-Geräten das Einspielen der Custom Recovery mittels "fastboot" erledigt wird, hat Samsung einen sogenannten "Download-Modus" implementiert, der auf dem Odin-Protokoll basiert. Die Installationsanleitung verweist hierfür auf "heimdall", eine freie Implementierung des Odin-Protokolls und gibt an:

Linux: Pick the appropriate package to install for your distribution. The -frontend packages aren’t needed for this guide. After installation, verify Heimdall is installed by running heimdall version in the terminal.

Leider stellt sich heraus, daß der Testbefehl

heimdall print-pit

mit der aktuell für alle Debian-Releases erhältlichen Heimdall Version v1.4.1 auf einen Fehler läuft:

$ heimdall print-pit
Heimdall v1.4.1
...
Downloading device's PIT file...
ERROR: Failed to send request to end PIT file transfer!
ERROR: Failed to download PIT file!
Ending session...
ERROR: Failed to send end session packet!
Releasing device interface...

Abhilfe schafft, sich den aktuellen Heimdall-Quellcode von GitLab zu organisieren (Klick auf das Symbol mit der Wolke und "Download") und anschließend selbst zu übersetzen. Eine Kurzanleitung findet sich im archivierten GitHub-Wiki und besteht im Wesentlichen darin, nach dem Installieren der erforderlichen Pakete

sudo apt-get install build-essential cmake zlib1g-dev qt5-default libusb-1.0-0-dev libgl1-mesa-glx libgl1-mesa-dev

die Entwicklungswerkzeuge ihre Arbeit erledigen zu lassen

$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ make

Anschließend findet sich im "bin"-Verzeichnis heimdall in der Version v1.4.2, mit der die Kommunikation dann problemlos funktioniert:

$ ./heimdall print-pit
Heimdall v1.4.2
...
Downloading device's PIT file...
PIT file download successful.

Entry Count: 43
...
Ending session...
Rebooting device...
Releasing device interface...

Nach erfolgreichem Test kann dann das Recovery auf das Tablet übertragen werden:

$ ./heimdall flash --RECOVERY twrp-3.3.1-0-gts210vewifi.img --no-reboot
Heimdall v1.4.2
...
Downloading device's PIT file...
PIT file download successful.

Uploading RECOVERY
100%
RECOVERY upload successful

Ending session...
Releasing device interface...

Nach dem erfolgreichen Flashen der Recovery steht ein weiterer Stolperstein im Weg: der Neustart. Das Wiki meint hierzu lediglich:

Manually reboot into recovery:
With the device powered off, hold Home + Volume Up + Power.

Leider lässt sich der Download-Modus nicht durch Drücken des "Power"-Buttons beenden, die einzige Möglichkeit bleibt, mittels "Power + Volume Down" einen Hard-Reset zu erzwingen um in dem Moment, in dem der Bildschirm dunkel wird, auf "Home + Volume Up + Power" zu wechseln, um so in der Recovery zu landen.

Ist dies geschafft, kann der Rest der Installation nach Fahrplan des Wikis erfolgen.