I suggest to install qmi, mbim and option drivers and a terminal program like picocom.
Then you should check if modeswitch will be able to switch this modem from Cfg#2 (ECM) to Cfg#1 (QMI) or Cfg#3 (MBIM).
Looks mostly like a bug. The device disconnects whenever the bConfiguration value is changed. Which makes it impossible to change it from detault, since every reconnect will place it into default again.
It would be good to have this behaviour verified before we dismiss it as implossible. @AneticsUk - could you please try the
as shown in that thread? You have to replace "x-y" with the actual bus and port values where your modem is connected. You can find these values e.g in the dmesg output when the modem is plugged in. Here it would be "1-2" for example:
usb 1-2: new high-speed USB device number 16 using xhci_hcd
And then show us the dmesg output when you do the echo. If the firmware isn't buggy, then you should be able to switch directly from cfg #2 to cfg #3 without an USB dsiconnect. Or from cfg #2 to cfg #0 (unconfigured) and then to cfg #3, all without the modem showing up as a new device in the log.
Some of the problem is caused by Linux preferring Class functions, ending up with cfg #2 instead of #1 as default. But this fact is somehow promising too. It means that Linux does manage to switch configs. Once.... The problem is that we don't have any tools affecting the choice. It will be 2. But if we're lucky, then the issue isn't the number of times this happens but how early. If so, then a properly configured usb-modeswitch should be able to work around that. I.e usb-modeswitch should be configured to auto-select the wanted configuration immediately after connect.
But if the firmware cannot change from the initial configuration at all, then I guess we'll have to add a new quirk. Not entirely sure what that would look like. Let's exhaust the other alternatives first...
(I was thinking that we could re-use the recent fix for the rtl8156 devices. But that will not prevent the config from being changed twice, so I guess it won't work any better than usb-modeswitch does)
I'm a bit sceptic about direct switching to another Cfg#, so I would first unconfigure with echo 0 >/sys/bus/usb/devices/x-y/bConfigurationValue or echo -1 >/sys/bus/usb/devices/x-y/bConfigurationValue
then echo 1 >/sys/bus/usb/devices/x-y/bConfigurationValue or echo 3 >/sys/bus/usb/devices/x-y/bConfigurationValue
@bmork do you think it will make sense to connect it under Windows to get AT command port working and then try to switch the configuration through AT command [that I don't know for this modem]?
Uncertain. We don't know shit about this modem. It doesn't look like it's eve known by the option or qmi_wwan drivers. Probably because no one has been able to switch it to a mode where that mattered. Which is one reason we'd prefer cfg #3 as it is. cfg #1 requires some additional work.