I’ve briefly looked into this, and I’m confident that it is possible to fix this based on the publically available docs, and some guesswork we’ve already done.
I assume the problem is caused by a Windows8 driver and/or application selecting a USB composition with MBIM only. As you may or may not know, SWI has documened how to change the USB composition using AT commands. This allows you to configure the modem for different combinations of AT+QMI or MBIM etc.
The challenge is that you don’t have access to the AT command channel anymore, so that cannot be used to configure the modem. Luckily, the latest version of the SWI Linux QMI SDK documents a couple of interesting SWI vendor specific QMI commands. If you look at the QMI Device Management Service (DMS) docs, you’ll find the two functions USBCompParams() and USBCompConfig(). I’m pretty sure the latter will do exactly the same as the AT command, allowing you do change the MBIM only composition to a more useful one.
Now, this still requires QMI and you only have MBIM. Here’s the magic: There is an undocumented (at least for those of us without a Qualcomm contract) vendor specific MBIM service present in most (all?) Qualcomm MBIM devices, allowing you to tunnel QMI inside MBIM. Nice, eh? By trial and error, I’ve determined that this is as “simple” doing an MBIM set operation on UUID d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3 CID 1, sending any QMI (QMUX) payload as data buffer. The response will have a raw QMI response as payload.
The only problem left is that there aren’t any ready-to-run tools available to use this info (well, it is likely that SWI and Qualcomm have such tools, but we don’t). So someone has to glue it all together:
- figure out exactly which QMI DMS command the referenced functions use (inspect the SDK)
- create a practical way to wrap the QMI command in MBIM (the Linux cdc_mbim driver provides the necessary USB transport, but there is no support for the QMI service in any of the userspace libraries)
- test everything and repeat until it works or the modem is bricked
I’d love to help, but realistically I am not going to be able to look at it at this side of the summer vacation.
Another option is of course that Sierra Wireless enter the scene and provide the necessary tool…
A third option is of course just to forget abot QMI and AT and use the modem with the cdc_mbim driver in Linux. It’s a nice driver 
EDIT: got curious enough about all this to do some initial experimenting (on an MC7710 in QMI mode). Here are a few more details for those who might want to work on this:
The QMI DMS messages are 0x555b for the “get USB comp” and 0x555c for the “set USB comp”. “get” returns two TLVs: 0x10 is the current selection (1 byte), 0x11 is a length (1 byte) prefixed array of available (1 byte) selections. The “set” message expects one TLV input: 0x01 is the new selection (1 byte). Which probably should be a valid one… I don’t dare trying anything invalid.
Sample QMI messages:
sending to /dev/cdc-wdm1:
01 0c 00 00 02 02 00 02 00 5b 55 00 00
=> QMUX Header:
=> len: 0x000c
=> sender: 0x00
=> svc: 0x02
=> cid: 0x02
=> QMI Header:
=> Flags: 0x00
=> TXN: 0x0002
=> Cmd: 0x555b
=> Size: 0x0000
reading from /dev/cdc-wdm1
[Tue Jun 30 18:13:26 2015] read 45 bytes from /dev/cdc-wdm1
01 2c 00 80 02 02 02 02 00 5b 55 20 00 02 04 00 00 00 00 00 10 01 00 13 11 12 00 11 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16
<= QMUX Header:
<= len: 0x002c
<= sender: 0x80
<= svc: 0x02
<= cid: 0x02
<= QMI Header:
<= Flags: 0x02
<= TXN: 0x0002
<= Cmd: 0x555b
<= Size: 0x0020
<= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
<= [0x10] ( 1) 13 .
<= [0x11] (18) 11 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 ..................which matches the output from the AT interface (the numbers above are in hex, so 0x13 = 19d):
at!udusbcomp?
!UDUSBCOMP: 19
OK
at!udusbcomp=?
0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS NOT SUPPORTED
1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED
2 - HIP DM NMEA AT NIC1 MS NOT SUPPORTED
3 - HIP DM NMEA AT MDM1 NIC1 MS NOT SUPPORTED
4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS NOT SUPPORTED
5 - HIP DM NMEA AT ECM1 MS NOT SUPPORTED
6 - DM NMEA AT QMI SUPPORTED
7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED
8 - DM NMEA AT MBIM SUPPORTED
9 - MBIM SUPPORTED
10 - NMEA MBIM SUPPORTED
11 - DM MBIM SUPPORTED
12 - DM NMEA MBIM SUPPORTED
13 - Config1: comp6 Config2: comp8 SUPPORTED
14 - Config1: comp6 Config2: comp9 SUPPORTED
15 - Config1: comp6 Config2: comp10 SUPPORTED
16 - Config1: comp6 Config2: comp11 SUPPORTED
17 - Config1: comp6 Config2: comp12 SUPPORTED
18 - Config1: comp7 Config2: comp8 SUPPORTED
19 - Config1: comp7 Config2: comp9 SUPPORTED
20 - Config1: comp7 Config2: comp10 SUPPORTED
21 - Config1: comp7 Config2: comp11 SUPPORTED
22 - Config1: comp7 Config2: comp12 SUPPORTED
OKAnd a “set” example:
sending to /dev/cdc-wdm1:
01 10 00 00 02 04 00 02 00 5c 55 04 00 01 01 00 0e
=> QMUX Header:
=> len: 0x0010
=> sender: 0x00
=> svc: 0x02
=> cid: 0x04
=> QMI Header:
=> Flags: 0x00
=> TXN: 0x0002
=> Cmd: 0x555c
=> Size: 0x0004
=> [0x01] ( 1) 0e .
reading from /dev/cdc-wdm1
[Tue Jun 30 18:14:38 2015] read 20 bytes from /dev/cdc-wdm1
01 13 00 80 02 04 02 02 00 5c 55 07 00 02 04 00 00 00 00 00
<= QMUX Header:
<= len: 0x0013
<= sender: 0x80
<= svc: 0x02
<= cid: 0x04
<= QMI Header:
<= Flags: 0x02
<= TXN: 0x0002
<= Cmd: 0x555c
<= Size: 0x0007
<= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONEVerified by the AT interface:
at!udusbcomp?
!UDUSBCOMP: 14
OKAll that’s missing is actually stiching all this together.
Note that the MC7710, and probably other Qualcomm based Sierra modules, have a firmware bug which allows you to talk QMI directly to it even if it is configured for MBIM. The firmware does not actually care about the mode. It always probes the messages it sees on the command channel, and selects the first protocol it sees. So if that is QMI then the firmware will speak QMI until it is reset.