I have connected one of them to WIndows, installed Windows drivers “GenericDriverSetup_Build4277” and “Skylight_Generic_Build4260.msi” the modem works OK on Windows BUT 1) does not work on LInux 2) does not expose nor COM port nor modem to issue AT commands
Second modem has been never connected to Windows, and it works OK on Linux with GobiNet and GobiSerial drivers. I was able to connect to 3G network with Sakis3G and download data with no problem.
My question is: how do I get back first modem to work on Linux? Please help me!
I have the exact same problem. The modem that has been plugged to Windows works properly in Windows. I get a network connectivity instantly. If I plug it back to my Linux board (which uses the GobiNet driver), it doesn’t show its /dev/qcqmiX interfaces nor its usbx network interfaces. Why is it? I have attached my dmesg output. I would be curious to compare it with OP’s one. dmesg output.txt (16.3 KB)
Very interested in hearing the solution here as I have the same problem. Had a MC7354 working in Linux and moved to a Windows 8 box to flash the modem the AT&T approved FW. Now when the unit is returned to Linux none of the USB serial ports are enumerated and I only get a single QMI port from the modem which doesn’t allow AT commands to issued to the unit. I appears the flash utility may have switched an operating modes.
This is normal. It is because the interfaces aren’t numbered consecutively. The numbering is instead used for function mapping. The warnings are harmless.
IMHO, the warning is more confusing than useful, although formally correct. But it has “always” been there, and some people find it useful. See the discussion in this thread for details: spinics.net/lists/linux-usb/msg77499.html
But back to your real problem (which is unrelated to the warning): Your modem is now configured with a single config having a single MBIM function. The modem should work fine with the Linux mainline cdc_mbim driver and MBIM aware userspace applications like ModemManager or umbim. But from your report I guess you expect an AT command function and/or QMI functions?
This is not correct. The last bytes are missing here. The final part should look like this:
22 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 xx
This is due to buffering in the reader. You won’t see the rest of this message until there is more data available. I’m afraid that is a challenge of this method. Did you use my suggested workaround of piping from dd:
dd if=/dev/cdc-wdm0 bs=1 |xxd -g1
Maybe that isn’t enough?
Yes, that is expected when the client ID is not allocated.
Someone (right should create a proper tool for doing this…
I had the same problem with mine. But the only way i could get it to expose serial ports for the MC7354 was to upgrade it to the 06.03.32.02 firmware, do an RMA reset command to OEM settings, downgrade it back to the version 5 firmware i wanted to use, connect to the AT command port and switch the USBCOMP setting to 8 (DM, MODEM, NMEA, MBIM).
The tricky part is (at least doing it through windows 8.1 or 10) that you need to be really quick and issue the proper commands to switch the composition before the Windows OS resets the device to MBIM only. (About 20 seconds) Otherwise you’re back to square one.
If you’re able to do this method, i would recommend using composition 8 only as it seems to be the only one that windows does not try to force back to MBIM only. I suspect this is due to the MBIM port already being active in it so the OS doesn’t bother switching the device. You still CAN use the QMI enabled compositions but the duration varies in how long it takes for your computer to realize that the compositions have been changed and try to get MBIM back somehow.
This problem only seems to affect the device if run on Windows 8/8.1/10 only. Windows 7 does not seem to try and force a similar change.
So i’m starting to wonder if the issue is not with the device or firmware itself, but a change in how the newer versions of windows are handling mobile broadband devices?
This fix resolved this issue for me.
See this thread.