Rolling Wireless RW350R-GL / Fibocom FM350R-GL (5G module) on Linux

We use ThinkPad X13 Gen 6 21RMCTO1WW laptops among others. They shipped with a 5G WWAN module that Lenovo sells as the “Rolling Wireless RW350R-GL 5G CAT19”. ModemManager detects it but cannot bring the radio up, because the module ships FCC-locked.

For the unlock procedure on Linux, Lenovo publishes lenovo-wwan-unlock. It works, but it is a closed binary running as root (sic!), supports only Ubuntu and Fedora, refuses to start on machines outside a hardcoded allowlist, and declines to unlock the modem when it finds a US SIM (for regulatory reasons, since it then assumes FCC jurisdiction). None of that is necessary. ModemManager has shipped a working unlock procedure for this module since version 1.24. It is just not enabled by default.

We have submitted a merge request that reads the OEM string at runtime instead of hardcoding one vendor’s value. Until it is merged and new ModemManager versions arrive downstream, the commands below may help you to get the module working today.

Which module is this?

The same piece of hardware appears under a lot of names, which makes searching for it frustrating. If any of these match your machine, this post applies to you:

Rolling Wireless was spun out of Sierra Wireless in 2020 and is now a Fibocom subsidiary, so the RW350R-GL is a rebadged FM350R-GL. Lenovo lists it for the X13 Gen 6 and Gen 7, the T14s 2-in-1 Gen 1, and the P16 and P16v Gen 3. Because ModemManager matches only on 14c3:4d75, the instructions below also cover the plain Fibocom FM350-GL in machines like the X1 Carbon Gen 10 and 11.

Enabling the unlock

If you installed lenovo-wwan-unlock before, remove it first. Its own script shadows the one from ModemManager, in /usr/lib64/ModemManager/fcc-unlock.d/ on Fedora and /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/ on Debian and Ubuntu. The uninstall script handles both:

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

Then enable ModemManager’s own script. Fedora, Debian and Ubuntu all ship it in the same place:

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"

The script needs xxd, which none of them install as a hard dependency:

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

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

Now shut the machine down completely. A warm reboot is not enough: the module keeps power across reboot and suspend, and only re-arms its lock when it loses power. After a cold boot the modem should come up on its own:

mmcli -L
nmcli device | grep gsm

Two harmless warnings

ModemManager logs this once during boot:

Cannot power-up: hardware radio switch is OFF

That is the FCC lock, not a physical switch or a soft block. Check rfkill list and you will see nothing blocked. The line is immediately followed by power state updated: on once the unlock script has run.

Uninstalling Lenovo’s package also strips --test-low-power-suspend-resume from the ModemManager unit, which its installer had added to stop the modem waking the machine from suspend. If you notice spurious wakeups afterwards, restore it as a drop-in rather than by editing the packaged unit:

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

What about SAR?

SAR, the specific absorption rate, is the regulatory limit on how much radio energy a body absorbs. The tables tell the modem to back off transmit power on the bands and in the situations where the antennas sit close to you.

Removing the Lenovo package does not remove them. configservice_lenovo is a provisioner rather than a runtime component: it compares a version string and writes the tables into the modem’s non-volatile memory only when they differ. On my machine, 127 runs produced exactly two writes, 1.02 in October 2025 and 1.1.3 in August 2026. Every other run logged bodysarver is same do not update.

The tables live in the module and the modem enforces them itself, so they survive reboots, suspend and uninstalling the package. What you give up is the updater: a newer table version will not be installed, and nothing re-provisions the modem after an NV wipe or a firmware reflash. Both are recoverable by reinstalling the package temporarily, letting it write, and removing it again (and I doubt one needs these updates at all).

To check the current state:

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

Note that Lenovo does not ship a table for every machine. On some models the service logs Lenovo Sar config is not supported in this machine, in which case nothing was ever written.

How the unlock works

No secret is involved. The modem answers AT+GTFCCLOCKGEN with a challenge, and the host replies with the first four bytes of SHA-256(challenge || SHA-256(model_id)[0:4]) via AT+GTFCCLOCKVER. The model_id is the first OEM string in SMBIOS type 133, which you can read yourself:

sudo dmidecode -t 133

On ThinkPads that string is KHOIHGIUCCHHII, and sha256sum of it starts with 3df8c719, exactly the constant in ModemManager’s script. Fibocom’s public FM350 AT command manual uses the same string as its worked example, in chapter 17.4.

Since that value is per vendor rather than per machine, hardcoding it means the script only works on the vendor it was taken from. A Dell Latitude 5540 with the same PCI ID fails for that reason, and Dell ships no SMBIOS type 133 string at all there, so reading it at runtime does not help either. Its value turned out to be DW5931EFCCLOCK, matching Dell’s own DW5931e branding.