Rescue MC7710 after incorrect PID change?

When trying to change the MC7100 from QMI to DIP mode, I mistakenly set the PID to 0x68b1 instead of 0x68a3, with the result that the device does not show any access ports, and so I cannot correct the mistake. This is with the MC7710 running under Linux on a MikroTik router board, and it should display as a USB device with 5 ports available. Now there are zero ports. It is also no longer recognized by the Windows (XP) driver that I used to update the firmware, so I cannot re-load or change the firmware.

On this forum there are two related postings. Apparently I have put the device in “a bad state”, or otherwise “non-composite mode”, but I have found nothing about what can be done to rescover from that. Is it possible in any way at all, or is it now trash?

Thanks for your attention,
Frank Bokhorst

It’s not clear to me whether you are referring to a driver or firmware problem. Could you post the USB descriptors as seen by the OS? I.e. “lsusb -vd 1199:68b1” or the relevant parts of /sys/kernel/debug/usb/devices (after ounting debugfs of course).

I don’t think it is a firmware problem. My mistake was to think that by re-loading the firmware I could fix the problem. But the descriptor I entered does not match the device and so the installed driver does not recognize it anymore. Windows XP device info now shows


And only that, I assume? Sorry, then I don’t know how to fix it. But I am pretty sure it is possible. Only one USB interface #0 looks very much like “bootloader mode” or “QDL mode”. Resurrecting the NVRAM settings from this mode is likely possible, but will require the assistance of someone with documentation on how to do that…

Yes, thanks for giving some suggestions. It now looks like it is worth trying and I will try to find out more!

The router OS does not give more specific information, but I put it into a Linux box and got the full descriptor listed in the attachment below. But note that lsusb gives an error message (Couldn’t open device…) because there is no driver available.

So it looks like only the product ID is incorrect. Before I messed up the product ID, the router OS listed 5 channels for this device, and the descriptor listing shows there are 5 interfaces, even though none is accessible. If everything else is correct for the MC7710 in the mode that I want to use, then it should be possible to rescue it if I can find a suitable driver and a way directly to change the product ID back to 68a3 without using AT commands.

Any clue how to do this would be appreciated.

I cannot download the attachment for some reason (“has been deleted”?). But if there are 5 interfaces then it is very likely that one or more are connected to the AT interpreter and will allow you to reset the ID. In Linux, try something like

modprobe option
echo 1199 68b1 >/sys/bus/usb-serial/drivers/option1/new_id

This should give you a number of ttyUSBx devices. Try them one by one and see if they respond to AT commands.

Could you explain with more detail? I understand it is to find out the name of the driver (“option”), then make an entry (echo 1199 68b1 > new_id) in the descriptor data used by the driver, and then reload the driver - correct?
But surely to get the correct ttyUSBx device we must give the driver the device ID 68a3?

On my system I find the descriptor data for the MC7710 are located in /sys/bus/usb/drivers/usb/1-3 and

$cat /sys/bus/usb/drivers/usb/1-3/idProduct

already gives 68b1 but there are no ttyUSBx devices. And sudo cannot change the entry for idProduct because it is read-only.

No, don’t reload the driver. You are adding a dynamic device entry to the driver. It will be gone when you unload the driver. What this tells the system is that it should try to use the option driver for all interfaces on the 1199:68b1 device. This driver is quite forgiving and should work fine with any serial interface present.

The Linux USB core will automatically try to bind any unbound device when new drivers are added, and also when you add dynamic IDs like this, so there is no need to do anything special after the command above. The /dev/ttyUSBx devices should magically appear. But don’t expect all of them to work. Some are probably not serial ports at all, and some of the serial ones won’t run an AT command interpreter.

But this doesn’t matter - all we need is a single /dev/ttyUSBx device which does speak AT commands.If one of them do, then success! You can then use the same procedure you used to change the PID to change it back.

No, we want to make a driver work with the current device ID, so that we can use a terminal application to change the device ID back.

Yes, but hopefully the procedure I gave above will create the ttyUSBx devices. It will NOT change the device ID. You will have to use the Sierra specific AT commands to do that. It will only allow you to enter those commands (assuming there is in fact an AT serial port there - let’s hope so).

Yes, devices cannot normally change their IDs. The Sierra implementation is very device and vendor specific. There is no generic support for this. You have to use the AT commands.

Good news!

After studying the Linux USB information I realized that in fact a driver for the MC7710 had been loaded, even though no ttyUSB devices were present. With this in mind I tried it with Ubuntu Linux and ModemManager for mobile broadband devices. That automatically recognized the MC7710 with device ID 68b1 and set up the connection like nothing was wrong. But still no ttyUSB ports.

After much trial-and-error I ended up running a legacy version (v9) of Ubuntu without ModemManager but an application called Sakis 3G. This loaded a proprietary Sierra driver that set up 5 USB ports and announced the MC7710 as a QMI modem. So apparently 68b1 is a QMI mode, but the USB ports is what I required.

I found that ttyUSB3 responded to AT commands and quickly set the Device ID back to 68a3 (DIP mode).

Now the Sierra driver for Windows XP recognizes the MC7710 again, and also RouterOS on the MikroTik router board.

Thank you very much for the positive suggestions!