(The same script and procedure worked fine on a dell branded EM7455)
The script ran through successfully, but after restarting the modem I neither have, qmi nor AT access. Basically no interface is created. There is neither a /dev/ttyUSB nor a /dev/cdc-wdm device.
The device is recognised by lsubs though.
dmesg says:
usb 2-2: config 1 has an invalid interface number: 8 but max is 3
usb 2-2: config 1 has no interface number 1
Attaching the same device to Windows, I only get a single unknown device:
USB\VID_1199&PID_9075&MI_08
With a little trial and error I was able to install a windows driver which translates to
Sierra Wireless EM7455 Qualcomm® Snapdragon™ swmbbnode device 03
But nothing else, it is also not usable in Windows.
Can some help by explaining what happened here, i.e. in which mode the modem is currently in? How can I leave it?
Yes, I would need to recompile, but that is actually not worth the effort for this cheap modem.
I am curious about the following. When I got the modem in usbmode 8 in the first place, i.e. with MBIM. The modem was recognised by the default windows driver and by the default linux driver…
Only when I changed the usbmode to 6 with QMI the driver issue occured.
I installed the driver but does not make any difference. For the sake of completeness:
[ 205.599820] usb 2-2: new high-speed USB device number 7 using xhci_hcd
[ 205.729817] usb 2-2: config 1 has an invalid interface number: 8 but max is 3
[ 205.729835] usb 2-2: config 1 has no interface number 1
[ 205.730436] usb 2-2: New USB device found, idVendor=1199, idProduct=9075, bcdDevice= 0.06
[ 205.730453] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 205.730461] usb 2-2: Product: EM7455
[ 205.730468] usb 2-2: Manufacturer: Sierra Wireless, Incorporated
[ 205.730473] usb 2-2: SerialNumber: LF91628890031028
Yes, that works. Modem is now accessible via qmi and tty. Thanks!
I then changed back the usbmode to 6 via the above mentioned perl script, which also worked and the modem is now accessible via mbim.
I hoped it will bring back to original state when I received it. In this state, the modem was recognised by windows and linux default drivers. It still isn’t. From my perspective due to the Fujitsu vid/pid.
Unfortunately I don’t know how the vid/pid was set in the beginning.
It it technically possible that the PID or something else was changed when I switched to usbmode 6 in the beginning?
Yes, I tried that. Flashed with the provided nvu on Windows . This did not change anything from a vid/pid perspective. However, user @phucha made use of the fdt flag “-d g5k”, which did not work for me.
On Linux I got an error during flashing. But honestly, I don’t even know what that nvu is doing and if it is even applicable to my case.
is @dl5162 still active here and can help? (I just noticed, he is also the one created the perl script I was using)
Sort of. Not very active and probably not much help. But at least I’m here
Note that the perl scripts we’re talking about are old experiments, which either died as experiments or moved on as real implementations in either libqmi or the kernel. Just mentioning it for anyone else reading this thread. There is no real point in running any of my old perl scripts. They were written because there were no other tools. Now there is.
Your EM7455 variant has probably had the same VID:PID all the time. This is a Fujitsu variant. Lenovo did the same. Both of these defaulted to MBIM, which is the only sane thing to for a laptop modem. MBIM is a USB-IF class specification, meaning that any MBIM device will work with any OS having an MBIM class driver. The VID:PID is irrelevant.
But these laptop variants are like any other EM7455 and can also be configured for RMNET/QMI. Which is a Qualcomm proprietary protocol. It shows up as a vendor specific function using ff/ff/ff for class/subclass/protocol. There is no way to tell whether this is a QMI function or a coffee maker without looking at the VID:PID. So the qmi_wwan driver has a very long device matching list (I counted 425 entries now) of mostly VID:PID + interface descriptors. Some of these catch more than one modem by assuming that all devices from a specific VID use the same interface descriptor pattern exclusively for QMI functions. But we never dared make that assumption for Sierra Wireless devices. We assume that interface number 8 is QMI on supported modems, but assuming that for any Sierra Wireless device seemed too risky at the time.
In retrospect I think we probably should have made a qmi_wwan match on VID 1199 and interface number 8, ignoring the PID. But it’s too late now for that to make any sense.
Long story. Back to your problem. There is no need to change the PID. You can still use it in QMI mode. You just have to add a new entry to the qmi_wwan driver like @jyijyi suggested.
You should also do the same with the qcserial driver, to get the ttyUSBx devices without any local hacks. Just copy the entries for e.g. the Lenovo part (1199:9079). It’s a single line in each driver. And please submit the patches upstream. That will make your modem instantly supported the next time you install Linux without you having to keep track of local patches. And it will help other users with the same variant.
Ah, thanks. People seem to still create tutorials based on this.
That’s the missing puzzle piece. It explains why it was working when I got it. I assumed it was configured in usbcomp 8 but in fact it was 9 (MBIM only). Obviously for usbcomp 8 I still have missing drivers for DM and AT. Now that all makes sense and if I switch back to 9 it works out of the box again on Linux and Windows. Oh boy…what a slow learning process…
Which I did. Only by doing this I was able to switch back to MBIM. BUT: What would be the preferred official way of switching from MBIM back to QMI if I cannot use AT or your perl script?
