polprog, 12.04.2026
A few weeks ago I got a new (old) laptop, a Lenovo P50 mobile workstation. I bought a compatible WWAN modem (Sierra Wireless AirPrime EM7455). The modem runs on a Qualcomm chipset. They require a small hack or configuration change to run uner Linux and ModemManager, if you want to use them for mobile broadband.
A lot of these modems, which are available online, have been uninstalled from existing laptops. You can get them as cheap as below $10 for a single modem. Getting these to run under Linux usually comes down to reconfiguring the modem to speak QMI. These modems usually show up as the following device:
Bus xxx Device yyy: ID 1199:9079 Sierra Wireless, Inc. EM7455
If your modem shows up like this, you likely just need to change the USB composition. Any guide for the EM7455 will work for you. In principle you just need to install the QMI utilities andand do
# Do not run this command if your modem has a different USB VID:PID than above!!!
# Read the rest of the text in that case
sudo qmicli -d /dev/cdc-wdm0 --dms-swi-set-usb-composition=6
because by default, the modems use the MBIM (Mobile Broadband Interface Model) interface which is a USB-defined standard instead of the QMI (Qualcomm MSM Interface), which is Qualcomm's proprietiary standard. On Linux however, all Qualcomm modems I dealt with use QMI and it seems to work well. The above command basically instructs the modem to switch it's USB composition from config 8 (default) to config 6:
sudo qmicli -d /dev/cdc-wdm0 --dms-swi-get-usb-composition
[/dev/cdc-wdm0] Successfully retrieved USB compositions:
[*] USB composition 6: DM, NMEA, AT, QMI
USB composition 8: DM, NMEA, AT, MBIM
USB composition 9: MBIM
This was not the case for me.
My modem had a different configuration. Instead it shows up as usb ID 1199:9075. As I later found out it also has a different unlock password and likely came from a Fujitsu laptop.
Bus xxx Device yyy: ID 1199:9075 Sierra Wireless, Inc. EM7455
The problem lies in the USB identification. As long as the modem speaks MBIM, qualcomm tools can communicate with it (because they support all 3 protocols). It all goes well, you set the USB composition, issue the modem reset command, it reboots and shows up in lsusb. And then no QMI devices show up. Without them, you cannot communicate with the modem, and it is essentially a soft brick.
Part of the problem lies in the Linux kernel. The QMI interface is provided as a character device /dev/cdc-wdmX by the qmi_wwan driver in the kernel. The qmi_wwan driver, like every USB driver has a list of USB VID:PID that it supports. The kernel knows all the lists and this way it know what driver to hand the device after the basic USB layer has been initialized.
If you look at the qmi_wwan source code, drivers/net/usb/qmi_wwan.c (for example here), it contains a large list of USB VIDs and PIDs which are handled by the driver. Right around line 1354 there are a few entries for our modem:
{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 10)},/* Sierra Wireless EM74xx */
{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 8)}, /* Sierra Wireless EM74xx */
{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 10)},/* Sierra Wireless EM74xx */
So, there are a few different possible VIDs and PIDs for the modem, and the 8 or 10 refers to the particular USB composition. You can see that the EM74xx series can either have 9079 or 907b as the product ID. This is because different vendors may ship different firmwares for the same modem and need to differentiate them. If you want to learn more why, there is an explanation at the end of the post.
Do you see the problem? The 1199:9075 device is not listed as handled by this driver. The soft-brick happens because Linux sees a 1199:9075 USB device, and no driver is known to the kernel that handles the device. The kernel therefore stops talking to the device, and you have no way to undo this change.
Fortunately there is a way to fix this. The fix comes in two parts. The first one is to get a way to talk to the modem at all. This can be done by a handy kernel module called option. The option module exposes a USB-serial interface to the modem. The nice part is that you can tell it an arbitrary VID:PID and it will try to attach the interface. To get the AT console for the modem, you just do (as root)
# modprobe option
# echo 1199 9075 > /sys/bus/usb-serial/drivers/option1/new_id
Now, four ttyUSB devices should come up. If memory serves me right, the device 2 is the AT interface (the remaining ones are either inactive, or GPS NMEA output if you have a GPS antenna connected - on my Sierra, it's the third unlabeled IPEX socket). You can check for the AT interface by using a serial terminal program like picocom and seeing if you get an OK answer when you type AT and hit enter.
# picocom /dev/ttyUSB2
Now you can issue AT commands to the modem. In principle you should be able to set up a PPP connection, but this way is not feasible for every day use. What we want to do is to unlock the developer mode in the modem to allow us to change the USB PID to something the qmi_wwan driver recognizes (that is, 9079).
The first command you want to sent is ATE to enable local echo, so you can see what you type.
The developer mode is locked behind a password. From most guides I read online, it seems that most modems have "A710" set as the password, and you enter it with the AT command:
AT!ENTERCND="A710"
Again, this was not the case for my modem. Fortunately the Qualcomm firmware has a backdoor which has been known for a while! There is a secret command that expects a challenge-response and will unlock the modem just like AT!ENTERCND does! The keygen is located in the edl repository here. In essence, you ask the modem for a challenge using
AT!OPENLOCK?
paste the code to the keygen and send back the response with AT!OPENLOCK=...
Once you are talking to the modem and you unlocked the developer mode, you can start to unbrick it. First of all, check if the radio works:
at!gstatus?
!GSTATUS:
Current Time: 60 Temperature: 28
Reset Counter: 2 Mode: ONLINE
System mode: WCDMA PS state: Not attached
WCDMA band: WCDMA 2100
WCDMA channel: 0
GMM (PS) state:DEREGISTERED NO SERVICE
MM (CS) state: IDLE NO SERVICE
WCDMA L1 state:L1M_DEEP_SLEEP LAC: 0000 (0)
RRC state: DISCONNECTED Cell ID: 00000000 (0)
RxM RSSI C0: --- RxD RSSI C0: ---
RxM RSSI C1: --- RxD RSSI C1: ---
(This is what my modem showed with the firmware mismatch, without a SIM card). If your modem says "LOW POWER MODE", please read on.
Next you want to check if the firmware preferece settings are correct:
AT!IMPREF?
!IMPREF:
preferred fw version: 02.39.00.00
preferred carrier name: GENERIC
preferred config name: GENERIC_002.085_000
calculated fw version: 02.39.00.00
calculated carrier name: GENERIC
calculated config name: GENERIC_002.085_000
current fw version: 02.24.05.06
current carrier name: GENERIC
current config name: GENERIC_002.026_000
fw version mismatch
config name mismatch
OK
Notice that the modem reported "fw version mismatch" and "config name mismatch". This cannot be a good thing. In my case I had to repair the settings to set the preferred version to the current version using the AT!IMPREF=... command
AT!IMPREF="02.24.05.06","GENERIC","GENERIC_002.026_000"
OK
AT!RESET
OK
Adjust the argument as necessary. At this point the modem resets. After reset you have to repeat the unlock procedure!
Once this is done, and the baseband boots up correctly, AT!GSTATUS? should return some network information:
!GSTATUS:
Current Time: 35 Temperature: 28
Reset Counter: 1 Mode: ONLINE
System mode: WCDMA PS state: Not attached
WCDMA band: WCDMA 2100
WCDMA channel: [REDACTED]
GMM (PS) state:DEREGISTERED NO IMSI
MM (CS) state: IDLE NO IMSI
WCDMA L1 state:L1M_PCH_SLEEP LAC: [REDACTED]
RRC state: DISCONNECTED Cell ID: [REDACTED]
RxM RSSI C0: --- RxD RSSI C0: ---
RxM RSSI C1: --- RxD RSSI C1: ---
OK
The LAC and Cell ID should not be zeros (it should be the LAC and CID of the nearby cell tower the modem talks to). If you have a SIM card that works, it should also associate to the network (after a little time) and show the RSSI values.
If you do not have a SIM card installed (why would you run a modem without one?), you can still list the available cellular networks using AT+COPS=?:
AT+COPS=?
+COPS: (1,"Orange PL","Orange","26003",7),(1,"T-Mobile.pl","TM PL","26002",7),(1,"Play","Play","26006",7),(1,"Plus","PLUS","26001",2),,(0,1,2,3,4),(0,1,2)
OK
(Note that the scan takes around a minute). These 4 networks are what you would see in most of Poland. If you can see the networks, it means the baseband (the radio part) is working.
The final step is to tell the modem to identify as something that the qmi_wwan driver can talk to. You can set an arbitrary USB Product ID using the AT!USBPID=... command:
at!usbpid=9075,9075
OK
The first parameter is BOOT PID, the second is normal operation PID. Once this is done, reset the modem again, best by AT!RESET. I guess you could also patch the qmi_wwan driver to recognize the Fujitsu's VID:PID and this way, only the composition switch would be needed.
Finally, you can set the default password to not have to use the keygen every time you want to reconfigure the modem. If you are in developer mode, you can just issue:
AT!SETCND="A710"
and this way set the de-facto default password. Wink, wink - AT!ENTERCND? prints the currently set password ;)
In my P50 I had a problem where ModeManager was unable to set the modem state to attach to the network. First of all, the modem needs to get an FCC unlock command. Originally this command is supposed to tell the modem that it's in an FCC approved device and can fire up the radios. How does the modem verify that? It doesn't. On debian, the command to enable doing this automatically is:
sudo ln -sft /etc/ModemManager/fcc-unlock.d /usr/share/ModemManager/fcc-unlock.available.d/*
If your modem returns "LOW POWER MODE" after asking it AT!GSTATUS?:
!GSTATUS:
Current Time: xxxx Temperature: 36
Reset Counter: 1 Mode: LOW POWER MODE
You need to set AT!PCOFFEN=2. This is related to a power saving mode which is enabled by asserting the W_DISABLE pin on the m.2 connector. The firmware may expect this, the P50 seems to not support this mode and the line is held in the wrong state. In my case this fixed it.
Once this is all done, you should be able to use ModemManager to configure the APN, user and password given by your operator and the networking should work.
and everyone else who posted various bits of trivia about this modem, who I dont remember, because I was trying to get this working for almost a week ;)
Due to RF regulations (Mostly FCC in the US, but also national agencies), manufacturers, who release products that use radio, are required to certify them. One would think that installing an FCC-approved modem in an FCC-approved laptop should result in an FCC approved system, but that is not the case (it is likely because the internal modem has an external antenna which is part of the laptop - so in principle, by installing it, you have changed the RF-active part of the system). The result of this logic is simple - a laptop and a modem form a particular certified system. Changing the modem changes the system, and in principle it must pass RF testing again.
This rule also requires the manufacturer to prevent the user from running a non-certified laptop+modem combo. It is the reason why all laptops have USB whitelists. If you install a non-approved Wi-Fi or WWAN card in a laptop, the BIOS/UEFI will not allow you to boot the system.
Sometimes manufacturers change some settings in the firmware and consider them necessary, so they adjust the USB PID to indicate that the modem is "theirs", and then only whitelist their custom PID. In principle, the firmware and the baseband are part of the RF system so if they are changed, this again invalidates the certification, and the system should prevent booting. A new USB VID:PID combo is considered a separate device which is why the qmi_wwan driver has such a huge list of supported devices, and multiple entries for the same modem hardware.
External USB modems dont have all this. That's because they have integrated (and integral) antennas, and they are certified as a whole device. Installing an external USB modem does not change it's RF characteristics, so you do not need to re-certify it after you plug it into a USB port. Except that plugging it into a USB port actually does change the RF characteristics of the antenna, because the laptop chassis acts as a ground plane. Some external USB stick modems also have an external antenna port option. This is a very complex topic :)
Internal modems in m2-to-USB or mPCIe-to-USB adapters, to which you connect external antennas (like in the image below) are technically a new RF system (since the modem was not tested with that particular antenna), so in theory you should re-certify them. This, in practice, is unenforceable. The sellers are selling adapters and antennas, not modems, so they are not selling active RF devices. The modems themselves have no antennas, so they cannot transmit any signals. It is you (the user) who assembles the radio system and you should make sure it's certified before you use it!! This is a grey area :-)
Sierra (or maybe Qualcomm?) recognized the general headache that USB whitelists cause to developers and engineers, and they have came up with a clever feature. The modem can delay it's USB enumeration upon power up - it will simply not report itself to the UEFI. This way the UEFI boots up as if there was no modem, and the modem shows up after some timeout from power on, supposedly, once the OS is already booted or booting. The OS sees a USB enumeration event. It's as if you plugged the modem into a USB port, except the port is an m.2 socket in the laptop and the modem was there all the time. The OS detects and sets up the modem and everything works (even though it should not ;) )
On the EM7455 this can be enabled by sending the AT command ("Fast USB enumeration")
at!custom="FASTENUMEN",0
once you unlock the developer mode on the modem with AT!ENTERCND=... or AT!OPENLOCK=... commands. The Sierra developer forum, is an absolute gold mine. (By the way, this is not a secret, it's in the developer manual for the modem)
> yea we know the bios whitelists suck
> you can just circumvent it, here's a handy firmware feature
~ Someone at Sierra, probably