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.

Manche Funktionsbezeichnungen lassen Interpretationsspielraum, wo besser keiner sein sollte. Die WordPress-Funktion "is_admin()" ist so ein Fall, denn wie die WordPress Code Refernce erklärt

Does not check if the user is an administrator

"is_admin()" prüft lediglich, ob der Aufruf innerhalb der Administrations-Oberfläche erfolgte. Wer sich für die tatsächlichen Berechtigungen des angemeldeten Benutzers interessiert, sollte "current_user_can()" verwenden.

Es gibt verschiedene Strategien, wie die Änderung einer Datei gespeichert werden kann. Die beiden i.d.R. eingesetzten Verfahren sind entweder die vorhandene Datei mit dem neuen Inhalt zu überschreiben oder aber den geänderten Inhalt in eine neue Datei zu speichern und dann die Dateien auszutauschen.

Unter Sicherheitsaspekten ist der Dateiaustausch klar vorzuziehen, denn erst wenn der neue Inhalt erfolgreich in die neue Datei gespeichert wurde, wird die bisherige Datei gelöscht. Beim direkten Überschreiben kann entweder beim Zugriff durch andere Programme eine halbfertige Datei geliefert werden oder es kommt durch Hardware- / Software-Fehler zu einer Situation, in welcher der alte Inhalt bereits zerstört, der neue Inhalt aber nicht erfolgreich geschrieben werden kann.

Dies hat Auswirkungen auf die Möglichkeiten, mittels inotifywait auf Dateiänderungen zu reagieren. Während beim direkten Überschreiben inotifywait ordnungsgemäß eine Änderung der Datei registriert, bricht inotifywait beim Dateiaustausch ab - die z.B. im Beitrag "Sass ohne Ruby" geschilderte Vorgehensweise scheitert dann, da die ursprünglich überwachte Datei ja nicht mehr existiert.

$ while inotifywait -e close_write style.scss; do sassc --style compact style.scss style.css ; done

Eine Möglichkeit, dies zum umgehen, ist das Überwachen des kompletten Verzeichnisses mit Abfrage der geänderten Datei

inotifywait -e close_write,moved_to,create -m . |
while read -r directory events filename; do
	if [ "$filename" = "style.scss" ]; then
		sassc --style compact style.scss .style.css
	fi
done

was aber - je nach Anzahl der im Verzeichnis vorhandenen Dateien und deren Änderungshäufigkeit - zu einer erhöhten Systemlast führen kann.

Soll das Skript, welches die WSUS-Updates genehmigt (oder ablehnt) nicht auf dem WSUS-Server selbst sondern auf einem anderen Server ausgeführt werden, scheitert dies zunächst mit der Fehlermeldung

Der Typ [Microsoft.UpdateServices.Administration.AdminProxy] wurde nicht gefunden.

Grund ist das Fehlen der benötigten Powershell-Cmdlets, welche zur Ausführung installiert werden müssen. Eine Suche im Internet führt meist in die falsche Richtung, nämlich zu Installationsanleitungen für die WSUS 3.0 SP2 Administration Console, welche aber für den unter Server 2019 verwendeten WSUS schon ein paar Tage zu alt ist.

Die benötigten Module lassen sich über den "Assistent zum Hinzufügen von Rollen und Features" installieren, hier ist unter "Features" der Punkt "Remoteserver-Verwaltungstools" / "Rollenverwaltungstools" / "Windows Server Upgrade Service-Tools" / "API- und PowerShell-Cmdlets" zu wählen.

Als letztes muß in dem Skript nur noch eine Zeile zum Zugriff auf den Remote-Server angepasst werden:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($serverName, $useSecureConnection, $portNumber)

Der Aufruf der Funktion "getUpdateServer" wird um die drei selbsterklärenden Parameter "$serverName", "$useSecureConnection" sowie "$portNumber" erweitert.

Wird auf Windows-Clients oft VirtualBox als Desktop-Virtualisierungslösung eigesetzt, stellt man nach dem Wechsel auf Debian fest, daß VirtualBox seit Buster nicht mehr in den Paketquellen enthalten ist.

Das Debian-Wiki empfieht als Ersatzlösung das auf QEMU/KVM basierende Paket virt-manager, welches in den "normalen" Paketquellen enthalten ist und somit einfach installiert werden kann:

$ sudo apt install virt-manager

Nach dem ersten Aufruf poppt erst einmal ein Fenster "System policy prevents management of local virtualized systems" zur Eingabe des Kennwortes hoch. Wer dies vermeiden möchte, kann seinen Benutzer der Gruppe "libvirt" hinzufügen:

$ sudo usermod -aG libvirt $(whoami)

Anschließend kann eine virtuelle Maschine aufgesetzt (und verwendet) werden.

Netzwerkbrücke

Je nach Anwendungsszenario stellt man sehr schnell fest, daß zwar die virtuelle Maschine ohne Probleme überall ins Netz kommunizieren kann, eine Kommunikation vom Host zur virtuellen Maschine hingegen nicht möglich ist.

Um dies zu ermöglichen, muß eine virtuelle Netzwerkbrücke eingerichtet werden. Hierzu schlagen die meisten per Suchmaschinen auffindbaren Lösungsmöglichkeiten vor, den Network-Manager zu deaktivieren und die Konfiguration der Netzwerkinterfaces komplett von Hand zu übernehmen, aber es funktioniert auch mittels Network-Manager, und das sogar recht einfach und elegant.

Zuerst einmal gilt es, die aktuelle Netzwerkverbindung sowie das verwendete Interface auszulesen, das in der Spalte "DEVICE" zu finden ist.

$ sudo nmcli connection show
NAME                         UUID  TYPE      DEVICE
Kabelgebundene Verbindung 1  ****  ethernet  enp3s0

Als nächstes wird die Brücke hinzugefügt, das Spanning Tree Protocol wird hierbei nicht benötigt.

$ sudo nmcli connection add type bridge ifname br0 stp no
Verbindung »bridge-br0« (****) erfolgreich hinzugefügt.

Die bestehende Netzwerkverbindung wird dann als Slave zur Brücke hinzugefügt, hierbei ist "enp3s0" durch das im ersten Schritt ermittelte Device zu ersetzen:

$ sudo nmcli connection add type bridge-slave ifname enp3s0 master br0
Verbindung »bridge-slave-enp3s0« (****) erfolgreich hinzugefügt

Wirft man einen Blick auf die nun vorhandenen Verbindungen, so werden neben der ursprünglichen Verbindung auch die beiden neuen Einträge angezeigt:

$ sudo nmcli connection show
NAME                         UUID  TYPE      DEVICE
Kabelgebundene Verbindung 1  ****  ethernet  enp3s0
bridge-br0                   ****  bridge    br0
bridge-slave-enp3s0          ****  ethernet  --

Als letzte Schritte folgen das Deaktivieren der bisherigen Verbindung und das Aktivieren der Netzwerkbrücke:

$ sudo nmcli connection down "Kabelgebundene Verbindung 1"
Verbindung »Kabelgebundene Verbindung 1« wurde erfolgreich deaktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/3)

$ sudo nmcli connection up bridge-br0
Verbindung wurde erfolgreich aktiviert (master waiting for slaves) (Aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/6)

Ein abschließender Blick auf die Verbindungen zeigt, daß die Umschaltung erfolgreich war:

$ sudo nmcli connection show
NAME                         UUID  TYPE      DEVICE
bridge-br0                   ****  bridge    br0
bridge-slave-enp3s0          ****  ethernet  enp3s0
Kabelgebundene Verbindung 1  ****  ethernet  --

Die so erzeugte Brücke kann dann in virt-manager für die Netzwerkverbindungen der virtuellen Maschinen verwendet werden:

Im entsprechenden Dialog ist aber eine Stolperfalle eingebaut: Im Feld "Brückenname" muß nicht der von nmcli ausgegebene NAME, sondern das DEVICE angegeben werden.