I have a WWAN device, which I foolishly bricked by overwriting vendor and product ID (VID and PID) using AT command. I did it in hopes to get around the laptop whitelist feature, which prevented laptop from starting when this card was plugged.

At this time, device is starting, and correctly pretending to be a different USB device, however Linux would no longer load correct driver for it, and for all intents and purposes it is inaccessible. I can no longer obtain serial port to it to revert back the VID/PID values.

Question: is there any way to tell Linux, when it sees the device 2cb7:0007 to internally substitute its id to 1199:9079, or at least to force load some driver which would allow me to get serial interface to it, so that I can revert identification? Perhaps I could use some other OS to do it?

1 Answer 1


You can see the module(s) that would be loaded for USB device with vendor:product IDs 1199:9079 with:

sudo modprobe -c | grep usb:v1199p9079

The results will be similar to:

alias usb:v1199p9079d*dc*dsc*dp*ic*isc*ip*in* qcserial
alias usb:v1199p9079d*dc*dsc*dp*ic*isc*ip*in08* qmi_wwan
alias usb:v1199p9079d*dc*dsc*dp*ic*isc*ip*in0A* qmi_wwan

indicating that for interface numbers 8 and 10 (0xA in hexadecimal), the module would be qmi_wwan, and qcserial would take control of any other interfaces of that device.

Most Linux USB-serial drivers have a way to tell the driver to try and accept a device it otherwise doesn't know about.

In this case, you should first blacklist (and rmmod if already loaded) any driver that would normally load for device 2cb7:0007, if such a driver exists. Then load the module manually with sudo modprobe qcserial, and write the device's current ID into /sys/bus/usb-serial/drivers/qcserial/new_id, like this:

echo "2cb7 0007" | sudo tee /sys/bus/usb-serial/drivers/qcserial/new_id >/dev/null

Because you just changed the ID values without making any alterations to how the device actually behaves, the driver should then be able to take control of the device as usual.

This is also how to deal with a device that has a built-in OEM USB-to-serial converter chip with customized vendor/product IDs: once you have identified the driver that can handle the actual chip used, you can use this mechanism to allow the driver to claim devices with that vendor/product ID pair even if the Linux serial driver developer is not aware of that particular custom vendor/product ID pair yet. Of course, in such a case it would be helpful to send an email to the maintainer of the appropriate serial driver describing the new IDs, so that future kernel versions will be able to identify such a customized OEM USB-to-serial chip automatically.

  • 1
    I wasn't sure if there's a solution, so at this time I solved the issue by recompiling kernel and modding qcserial.c to accept the bad ID as if it was its own. This fixed the problem, but now I'm intrigued whether your solution would have worked too. I shall overwrite ID once more to test whether it will
    – galets
    Commented Mar 3 at 15:38
  • 2
    It works!!!!!!!
    – galets
    Commented Mar 3 at 16:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .