Für die Unlocking-Procedure unter Linux veröffentlicht Lenovo lenovo-wwan-unlock. Das funktioniert, ist aber ein geschlossenes Binary mit Root-Rechten (sic!), unterstützt nur Ubuntu und Fedora, verweigert den Dienst auf Geräten außerhalb einer fest eingebauten Positivliste und entsperrt das Modem nicht, wenn es eine US-SIM findet (aus regulatorischen Gründen / da es eine FCC-Zuständigkeit annimmt). Nichts davon ist nötig. ModemManager bringt seit Version 1.24 ein passendes Unlock-Verfahren mit, es ist nur nicht standardmäßig aktiviert.

Wir haben einen Merge Request eingereicht, der den OEM-String zur Laufzeit ausliest, statt den Wert eines einzelnen Herstellers fest einzutragen. Bis dieser eingebaut ist und neue ModemManager-Versionen downstream ankommen, helfen eventuell die folgenden Befehle, um das Modem in Betrieb nehmen zu können.

Um welches Modul(e) geht es?

Dieselbe Hardware taucht unter vielen Namen auf, was die Suche danach mühsam macht. Passt eine Bezeichnung davon zum Deinem Gerät, kann Dir dieser Beitrag weiterhelfen:

Rolling Wireless wurde 2020 aus Sierra Wireless ausgegliedert und gehört inzwischen zu Fibocom, das RW350R-GL ist also ein umgelabeltes FM350R-GL. Lenovo führt es für X13 Gen 6 und Gen 7, T14s 2-in-1 Gen 1 sowie P16 und P16v Gen 3. Da ModemManager nur auf 14c3:4d75 prüft, gilt die folgende Anleitung ebenso für das einfache Fibocom FM350-GL, etwa im X1 Carbon Gen 10 und 11.

Unlock aktivieren

Falls lenovo-wwan-unlock bereits installiert ist, sollte man es zuerst entfernen. Dessen eigenes Skript überdeckt sonst die ModemManager-Lösung, unter Fedora in /usr/lib64/ModemManager/fcc-unlock.d/, unter Debian und Ubuntu in /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/. Das Uninstall-Skript deckt beide Fälle ab:

git clone https://github.com/lenovo/lenovo-wwan-unlock.git
cd lenovo-wwan-unlock && chmod ugo+x fcc_unlock_uninstall.sh && ./fcc_unlock_uninstall.sh

Anschließend muss man das von ModemManager mitgelieferte Skript aktivieren. Fedora, Debian und Ubuntu liefern es an derselben Stelle aus:

sudo install -d -m 0755 "/etc/ModemManager/fcc-unlock.d"
sudo ln -s -f "/usr/share/ModemManager/fcc-unlock.available.d/14c3" \
              "/etc/ModemManager/fcc-unlock.d/14c3:4d75"

Das Skript benötigt xxd, das keine der Distributionen als harte Abhängigkeit mitzieht:

# Fedora / Red Hat
rpm -q xxd || sudo dnf install xxd

# Debian und Ubuntu
dpkg -s xxd > /dev/null 2>&1 || sudo apt install xxd

Jetzt das Gerät vollständig herunterfahren. Ein Warmstart / Reboot genügt nicht: Das Modul behält über Reboot und Suspend hinweg seine Stromversorgung und aktiviert die Sperre erst wieder, wenn es stromlos wird. Nach einem Kaltstart sollte das Modem von selbst hochkommen:

mmcli -L
nmcli device | grep gsm

Zwei harmlose Warnungen

ModemManager protokolliert beim Booten einmalig:

Cannot power-up: hardware radio switch is OFF

Das ist die FCC-Sperre und weder ein Hardware-Schalter noch ein Soft-Block. Ein Blick in rfkill list zeigt nichts Blockiertes. Direkt danach folgt power state updated: on, sobald das Unlock-Skript durchgelaufen ist.

Die Deinstallation von Lenovos Paket entfernt außerdem --test-low-power-suspend-resume aus der ModemManager-Unit. Lenovos Installer ergänzt diesen Parameter, damit das Modem den Rechner nicht aus dem Suspend weckt. Falls danach sporadische Aufwachvorgänge auftreten, sollte man es als Drop-in wiederherstellen statt die paketierte Unit zu bearbeiten:

sudo install -d "/etc/systemd/system/ModemManager.service.d"
printf '[Service]\nExecStart=\nExecStart=/usr/bin/ModemManager --test-low-power-suspend-resume\n' \
  | sudo tee "/etc/systemd/system/ModemManager.service.d/10-low-power-suspend.conf"
sudo systemctl daemon-reload

Was ist mit SAR?

SAR, die spezifische Absorptionsrate, ist der regulatorische Grenzwert dafür, wie viel Funkenergie ein Körper aufnimmt. Die zugehörigen Tabellen weisen das Modem an, die Sendeleistung in den Bändern und Situationen zu senken, in denen die Antennen nah am Körper sitzen.

Das Entfernen des Lenovo-Pakets entfernt die Tabellen nicht. configservice_lenovo ist ein Provisionierer und keine dauerhaft laufende Komponente: Es vergleicht eine Versionsnummer und schreibt die Tabellen nur dann in den nichtflüchtigen Speicher des Modems, wenn sie abweichen. Auf meinem eigenen Gerät ergaben 127 Läufe genau zwei Schreibvorgänge, 1.02 im Oktober 2025 und 1.1.3 im August 2026. Alle übrigen Läufe protokollierten bodysarver is same do not update.

Die Tabellen liegen im Modul und das Modem enforced sie selbst, d.h. sie überstehen Neustarts, Suspend und die Deinstallation des Pakets. Was wegfällt, ist die Aktualisierung: Eine neuere Tabellenversion wird nicht mehr eingespielt, und nach einem NV-Reset oder einem Firmware-Flash provisioniert nichts mehr nach. Beides lässt sich beheben, indem man das Paket kurzzeitig erneut installiert, schreiben lässt und wieder entfernt (und es ist fraglich, ob man die Updates überhaupt braucht).

Zum Prüfen des aktuellen Stands:

sudo mbimcli -p -d /dev/wwan0mbim0 --fibocom-set-at-command='AT+BODYSAREN?'
sudo mbimcli -p -d /dev/wwan0mbim0 --fibocom-set-at-command='AT+BODYSARVER?'

Lenovo liefert nicht für jedes Gerät eine Tabelle. Auf manchen Modellen protokolliert der Dienst Lenovo Sar config is not supported in this machine, dann wurde nie etwas geschrieben.

Wie der Unlock funktioniert

Ein Geheimnis ist nicht im Spiel. Das Modem antwortet auf AT+GTFCCLOCKGEN mit einer Challenge, der Host schickt via AT+GTFCCLOCKVER die ersten vier Bytes von SHA-256(challenge || SHA-256(model_id)[0:4]) zurück. Die model_id ist der erste OEM-String in SMBIOS-Typ 133 und lässt sich selbst auslesen:

sudo dmidecode -t 133

Auf ThinkPads lautet dieser String KHOIHGIUCCHHII, dessen sha256sum mit 3df8c719 beginnt, exakt der Konstante im Skript von ModemManager. Fibocoms öffentliches AT-Command-Handbuch zum FM350 verwendet denselben String als Beispiel (vgl. Kapitel 17.4). Da der Wert pro Hersteller und nicht pro Gerät gilt, funktioniert ein fest eingetragener Wert nicht für alle Hersteller. Ein Dell Latitude 5540 mit derselben PCI-ID scheitert aus diesem Grund; zudem liefert Dell dort überhaupt keinen SMBIOS-String vom Typ 133 aus, sodass auch das Auslesen zur Laufzeit nicht weiterhilft. Der Wert stellte sich in diesem Fall aber als DW5931EFCCLOCK heraus, was der eigenen Bezeichnung “DW5931e” von Dell entspricht.