The frustration with WWAN support on ThinkPads under Linux is well-documented. You buy a laptop with an embedded LTE or 5G modem, boot into Linux, and discover that getting the modem to fully operate requires either a Windows detour or a community-written workaround. This writeup about replacing Lenovo’s WWAN unlock blob with a 100-line bash script sits squarely in that tradition, but it’s worth unpacking why this kind of reverse engineering matters beyond the immediate “now it works” payoff.
What the Unlock Is Actually For
The term “WWAN unlock” covers several distinct problems, and conflating them causes confusion. There is the BIOS hardware whitelist, the FCC unlock, and carrier locking. They are separate mechanisms.
ThinkPads infamously enforced a hardware whitelist for many years, rejecting non-approved cards with the message “1802: Unauthorized network card is plugged in” at POST. That check was purely BIOS-level. The ThinkWiki documented extensive BIOS patching procedures for bypassing it, and Lenovo eventually dropped the practice on newer models.
The FCC unlock is different and more relevant here. The FCC requires that embedded modems in devices sold in the United States implement access controls over radio configuration, but also mandates that end users have a path to unlock them for legitimate use. Modem manufacturers implement this as an authenticated command sequence, and that sequence must be triggered before the modem enters its full operational state. Lenovo’s blob almost certainly exists to handle this, sending the appropriate commands to the modem during setup.
Carrier locking, where the modem is constrained to a specific carrier’s SIM, is not something Lenovo typically applies to ThinkPads, so it is unlikely to be the focus here.
The Protocol Stack Underneath
Modern embedded modems in ThinkPads speak one of two main protocols: QMI (Qualcomm MSM Interface) or MBIM (Mobile Broadband Interface Model).
QMI is Qualcomm’s proprietary protocol, used by Sierra Wireless modems such as the EM7455 and EM7565 that appeared in many ThinkPad generations through roughly 2020. It exposes a character device, typically /dev/cdc-wdm0, and the Linux userspace interface comes from libqmi and its companion tool qmicli. The FCC unlock on these modems is a single command:
qmicli -d /dev/cdc-wdm0 --dms-set-fcc-authenticationThat is it. One line. The Sierra Wireless EM7455 in many ThinkPad X1 Carbon and T-series machines across multiple generations unlocks with that command, and this has been known in the Linux community for years. The libqmi project documents the DMS (Device Management Service) interface thoroughly.
MBIM is the USB Implementers Forum-standardized alternative, used by Intel’s XMM modem series. The Fibocom L850-GL (based on Intel XMM7560) and the newer FM350-GL appear in ThinkPads from roughly 2019 onward. MBIM support comes from libmbim and mbimcli. The protocol is more standardized than QMI, but modems frequently expose vendor-specific extensions through Microsoft’s MS-MBIM extensions, which adds its own complications.
ModemManager sits above both, providing a unified D-Bus API and handling the state machine for modem initialization, SIM management, and bearer setup. When everything works correctly, you interact with ModemManager and never touch QMI or MBIM directly. When something does not work, you absolutely do.
What a Blob Hides
Lenovo ships Windows software for modem initialization and firmware updates. On Linux, the official story is either nothing, or a UEFI capsule-based firmware updater that runs outside the OS. The WWAN unlock blob in question is likely a compiled binary, possibly a Linux ELF, possibly a UEFI application, that wraps the same underlying command sequences the open tools expose.
Beyond the obvious inability to read the code, blobs introduce several concrete problems.
First, they create a runtime dependency on the vendor’s maintenance timeline. When Lenovo stops shipping the binary, or when it targets a specific kernel ABI that evolves, it breaks. A bash script using stable qmicli or mbimcli interfaces has no such fragility. Those interfaces are maintained by the freedesktop.org mobile broadband stack, which has been stable for years and is actively developed.
Second, you cannot audit what the binary does. Something that communicates directly with your modem’s firmware, which contains its own processor and handles radio transmissions, has a meaningful attack surface. Most vendor utilities do exactly what they claim. The assurance “most of the time” is structurally weaker than “here is every command being sent.”
Third, debugging failures is nearly impossible. A binary returns an exit code. A bash script accepts set -x and shows you every command, every argument, and every response.
The Shape of a 100-Line Replacement
The script described in the article almost certainly handles a handful of concerns: finding the correct /dev/cdc-wdm* device when multiple USB serial interfaces are present, detecting which protocol the modem uses, sending the unlock command, and possibly resetting the modem afterward to ensure the change takes effect. Here is roughly the structure such a script would follow:
#!/usr/bin/env bash
set -euo pipefail
DEVICE=$(find /dev -name 'cdc-wdm*' | head -1)
if [ -z "$DEVICE" ]; then
echo "No WWAN device found" >&2
exit 1
fi
# Qualcomm/QMI path (Sierra Wireless EM7455, EM7565, etc.)
if qmicli -d "$DEVICE" --dms-get-manufacturer 2>/dev/null | grep -qi qualcomm; then
echo "QMI modem detected, sending FCC auth..."
qmicli -d "$DEVICE" --dms-set-fcc-authentication
# MBIM path (Fibocom L850-GL, FM350-GL, etc.)
elif mbimcli -d "$DEVICE" --query-device-caps 2>/dev/null; then
echo "MBIM modem detected, sending unlock sequence..."
mbimcli -d "$DEVICE" \
--device-open-proxy \
--ms-set-device-service-session-info="..."
fiThe real script handles edge cases, supports multiple modem variants that use slightly different command parameters, and probably includes version checks. But the core is this compact. The blob was doing the same operations, compiled into a form that obscures them.
A Pattern That Keeps Repeating
The Linux community has been working around Lenovo’s modem policies for a long time. The 1802 whitelist problem consumed ThinkPad forums from around 2004 through the mid-2010s. Dedicated tools like no-1802 and various BIOS patching utilities kept appearing. Lenovo eventually stopped enforcing the whitelist on newer hardware, not because of community pressure specifically, but because the market calculus shifted.
The WWAN unlock situation is structurally identical: hardware that works fine, gated behind a vendor-controlled software procedure, with the Linux community finding the path around it.
What has changed is the quality of the underlying tooling. libqmi reached a solid state around 2015, covering the full QMI DMS including FCC authentication. libmbim matured on a similar schedule. ModemManager, developed primarily by Aleksander Morgado over many years across Lanedo and Purism, unified both under a coherent interface. The freedesktop.org mobile broadband stack is genuinely robust software at this point, and the project is actively maintained.
That infrastructure is what makes a 100-line bash replacement possible. Without qmicli and mbimcli, you would be constructing raw USB control transfers yourself, reading the QMI specification PDFs, and handling modem-specific quirks with no prior art. The script author stands on years of community work.
Why This Matters Beyond the Fix
The deeper question is why Lenovo continues shipping opaque binaries for operations that well-maintained open tooling handles directly. Part of the answer is organizational: the Windows utilities team and the Linux integration team are not the same people, and coordination across them is not a high priority. Part may be legal: the blob could embed Qualcomm or Intel firmware-adjacent IP that Lenovo has constraints around distributing as source. Part is straightforward inertia.
The result, reliably, is that someone reverse-engineers the blob, writes a clean replacement, and publishes it. This cycle has played out with firmware update paths, ACPI table patches, fan control daemons, and now WWAN unlock. The community does the work that should have been done upstream.
The 100-line bash script is not only a workaround. It is documentation. It records precisely what the blob was doing, in a form that is readable, modifiable, and executable without trusting an opaque binary. That matters independently of whether it solves any individual’s modem problem.
Hardware that works on Linux because someone spent a weekend with usbmon, strace, and AT command documentation is hardware that continues working long after the vendor’s maintenance window closes. Blobs accumulate bit-rot. Scripts stay legible.