My MC7710 can't work on Linux after plug-in it to Windows8

IoT Modules MC/EM Series
1

Hi,

I have a MC7710 module.
It works well on Linux before.
I can see ttyUSB0, ttyUSB1 and ttyUSB2 after install GobiSerial driver.
I also can see qcqmi0 after install GobiNet driver.
But all of them disappear now after I try to plug-in my modules to Windows8 host and dial-up LTE with SkyLight connection manager.

I found there are some difference for the messages by cat /proc/bus/usb/devices.

===== While my module is workable on before, the message are as below =====
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1199 ProdID=68a2 Rev= 0.06
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=MC7710
S: SerialNumber=358178041502180
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=GobiSerial
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=GobiSerial
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=GobiSerial
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=GobiNet
E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms

===== After become to unworkable, the messages are as below =====
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1199 ProdID=68a2 Rev= 0.06
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=MC7710
S: SerialNumber=358178041502354
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr= 0mA
A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
I: If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms

Additionally, I see messages as below while power on which should imply something wrong.
usb 1-1: new high speed USB device number 3 using xhc_mtk
usb 1-1: config 1 has an invalid interface number: 12 but max is 1
usb 1-1: config 1 has an invalid interface number: 13 but max is 1
usb 1-1: config 1 has an invalid interface number: 13 but max is 1
usb 1-1: config 1 has no interface number 0
usb 1-1: config 1 has no interface number 1

It doubts some settings on my module are changed by windows driver or connection manager.
Could someone please provide some suggestion to me for recover my MC7710 module?

Thanks.

BR
Ricky

2

I search on Google and found it seems the issue is caused by windows 8.1 switch my MC7710 module to MBIM mode.
But don’t find how to switch my module from MBIM to QMI.

Ricky

3

Um…the device class is changed from “Cls=00(>ifc ) Sub=00 Prot=00” to “Cls=ef(misc ) Sub=02 Prot=01”.
I search a lot of info from google.
But I can’t find the solution so far.
Have anyone know how to change it back?
I will appreciate your any comments.
Thanks.

Ricky

4

Hi rickyUm,

I have the same problem with the MC7354 modem. Have you found anything so far? I’ll let you know if I discover something on my side.

5

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:

  1. figure out exactly which QMI DMS command the referenced functions use (inspect the SDK)
  2. 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)
  3. test everything and repeat until it works or the modem is bricked :wink:

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 :slight_smile:

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


OK

And 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_NONE

Verified by the AT interface:

at!udusbcomp?
!UDUSBCOMP: 14

OK

All 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.

6

Hi, Brio3GMaster,

Unfortunately, I didn’t find the proper solution to switch my MC7710 modems back to QMI+AT mode after search a lot of info from internet.
I just look into dl5162’s comments.
Maybe I will find time to try it.

Hi, dl5162,
appreciate your kindly reply.

BR
Ricky

7

I’d would be curious if anyone has an answer to this. I have the same problem listed on another post on this forum. Why does the card not support QMI after going into Windows and convert to MBIM? Couldn’t firmware allow it to support both or reset back to QMI or something default and let the OS change it to what it needs?

I tried for two weeks to get it to reset on multiple MC cards without luck. I ended up sending mine in for RMA…

8

OK, I’m not going to get around to coding anything, so here’s a completely untested manual procedure for the brave. I don’t know if this works, so I’d sure be happy to hear about any success/failures/bricks…

  1. You need a Linux system with the cdc_mbim driver. This should provide a /dev/cdc-wdm0 device interface to the MBIM control channel. Make sure no other software tries to use it! Use e.g. “lsof /dev/cdc-wdm0” to verify

  2. Set up some reader process without buffering, allowing you to see the replies from the modem. E.g.

dd if=/dev/cdc-wdm0 bs=1 |xxd -g1

or whatever your preference is. Note that you have to prevent buffering here.

  1. You can now start writing MBIM messages in another terminal, like MBIM OPEN:

echo 01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 00 |xxd -r -p >/dev/cdc-wdm0

You should see

0000000: 01 00 00 80 10 00 00 00 01 00 00 00 00 00 00 00 …

in in the reader terminal window. If not, then something failed and there is no point continuing.

  1. Request a QMI DMS CID:

echo 03 00 00 00 40 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 10 00 00 00 01 0f 00 00 00 00 00 04 22 00 04 00 01 01 00 02 |xxd -r -p >/dev/cdc-wdm0

expected response:

03 00 00 80 48 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 18 00 00 00 01 17 00 80 00 00 01 04 22 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 xx

Note the xx number (last byte in the reply). This is the allocated CID. You have to use that number in the next commands.

  1. (Optional) Check the list of supported USB configurations:

echo 03 00 00 00 3d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 0d 00 00 00 01 0c 00 00 02 xx 00 06 00 5b 55 00 00 |xxd -r -p >/dev/cdc-wdm0

expected response. Maybe slightly different, depending on the exact list of supported configs:

03 00 00 80 5d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 2d 00 00 00 01 2c 00 80 02 xx 02 06 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

The number in blue indicates the active configuration (note that all these numbers are in hex, so this is 0x13 or 19 in decimal). The green numbers are the supported configurations. See my previous post for their exact meaning.

  1. Try to change the current configuration into something from with QMI and AT functions. Make sure the selected value is in the list of supported values if you did step #4. But 6 is usually a safe bet in any case. The last byte (in green) is the requested new configuration:

echo 03 00 00 00 3d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 11 00 00 00 01 10 00 00 02 xx 00 08 00 5c 55 04 00 01 01 00 06 |xxd -r -p >/dev/cdc-wdm0

expected response:

03 00 00 80 5d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 14 00 00 00 01 13 00 80 02 xx 02 08 00 5c 55 07 00 02 04 00 00 00 00 00

  1. If that succeeded then you should finish the session:

release the DMS CID

echo 03 00 00 00 41 00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 11 00 00 00 01 10 00 00 00 00 00 08 23 00 05 00 01 02 00 02 xx |xxd -r -p >/dev/cdc-wdm0

expected response:

03 00 00 80 48 00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 18 00 00 00 01 17 00 80 00 00 01 08 23 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 xx

Close the MBIM session:

echo 02 00 00 00 0c 00 00 00 0a 00 00 00 |xxd -r -p >/dev/cdc-wdm0

expected response:

02 00 00 80 10 00 00 00 0a 00 00 00 00 00 00 00

  1. reset the modem and hope for the best.

Note that this was all typed and never tested, so there are likely errors to be corrected in the above. Please try to understand what’s happening, and correct as necessary. It’s usually not a problem if you send some invalid command to the modem. They will either be ignored or result in an error message back.

9

[quote=“dl5162”]
OK, I’m not going to get around to coding anything, so here’s a completely untested manual procedure for the brave. I don’t know if this works, so I’d sure be happy to hear about any success/failures/bricks…

  1. You need a Linux system with the cdc_mbim driver. This should provide a /dev/cdc-wdm0 device interface to the MBIM control channel. Make sure no other software tries to use it! Use e.g. “lsof /dev/cdc-wdm0” to verify

  2. Set up some reader process without buffering, allowing you to see the replies from the modem. E.g.

dd if=/dev/cdc-wdm0 bs=1 |xxd -g1

or whatever your preference is. Note that you have to prevent buffering here.

  1. You can now start writing MBIM messages in another terminal, like MBIM OPEN:

echo 01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 00 |xxd -r -p >/dev/cdc-wdm0

You should see

0000000: 01 00 00 80 10 00 00 00 01 00 00 00 00 00 00 00 …

in in the reader terminal window. If not, then something failed and there is no point continuing.

  1. Request a QMI DMS CID:

echo 03 00 00 00 40 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 10 00 00 00 01 0f 00 00 00 00 00 04 22 00 04 00 01 01 00 02 |xxd -r -p >/dev/cdc-wdm0

expected response:

03 00 00 80 48 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 18 00 00 00 01 17 00 80 00 00 01 04 22 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 xx

Note the xx number (last byte in the reply). This is the allocated CID. You have to use that number in the next commands.
[/quote=“dl5162”]
So i get to about this point where i’m requesting the DMS CID number but i get cut off on the second line just following “…80 00 00 01 04 22 00 0c 00 02 04” and thats about it. However by luck, some extra data came through and cleared the rest of the buffer so i was able to retrieve the CID anyways.

[quote=“dl5162”]
4. (Optional) Check the list of supported USB configurations:

echo 03 00 00 00 3d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 0d 00 00 00 01 0c 00 00 02 xx 00 06 00 5b 55 00 00 |xxd -r -p >/dev/cdc-wdm0

expected response. Maybe slightly different, depending on the exact list of supported configs:

03 00 00 80 5d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 2d 00 00 00 01 2c 00 80 02 xx 02 06 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

The number in blue indicates the active configuration (note that all these numbers are in hex, so this is 0x13 or 19 in decimal). The green numbers are the supported configurations. See my previous post for their exact meaning.
[/quote=“dl5162”]
Step 4 works just fine so far

[quote=“dl5162”]
5. Try to change the current configuration into something from with QMI and AT functions. Make sure the selected value is in the list of supported values if you did step #4. But 6 is usually a safe bet in any case. The last byte (in green) is the requested new configuration:

echo 03 00 00 00 3d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 01 00 00 00 11 00 00 00 01 10 00 00 02 xx 00 08 00 5c 55 04 00 01 01 00 06 |xxd -r -p >/dev/cdc-wdm0

expected response:

03 00 00 80 5d 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 14 00 00 00 01 13 00 80 02 xx 02 08 00 5c 55 07 00 02 04 00 00 00 00 00
[/quote=“dl5162”]
This is the part where im stuck. I send the request but all i get is one line of code that looks nothing like what you have above. I know in the AT interface you need to enter the proprietary password "AT!ENTERCND=“A710” for the MC7354 and after a little digging on google, i also found out that Sierra’s QMI interface sends a special FCC Auth code to unlock certain commands like this one. Would issuing this auth code (0x555F in DMS service https://sigquit.wordpress.com/tag/libqmi/ ) fix the problem im having above? and if so, how would you issue it in the way you have it above?

10

What does it look like?

No, no password is necessary. At least not with my MC7710. The password protection is probably part of the AT command interpreter and does not apply to other command interfaces like QMI or MBIM.

The FCC Auth thing is a different issue. The only relationship is that it is another example of a Sierra Wireless vendor specific QMI DMS message.

11

0a 0b 0c 0d 0e 0f 10 11 12 14 02 00 00 80 53 00 00 00

Its not really useful though. I’ve shut off all the buffer settings i could think of, but its still buffering the responses i get, and doesn’t dump it until the next piece of data comes through

12

If you are really brave, then you could try a perl script I hacked together based on the MBIM and QMI code I used while developing the drivers:
git.mork.no/?p=wwan.git;a=blob_p … usbcomp.pl

I have tested it on an MC7710 and an EM7305 and it seems to do the job for me. I tried configuring the EM7305 for MBIM only (although it still showed the DM channel):

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 17 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1199 ProdID=9041 Rev= 0.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=EM7305
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

And then I ran the script with a “–usbcomp=19” parameter:

./swi_setusbcomp.pl --device=/dev/cdc-wdm2 --usbcomp=19

which provided the current setting before changing it to 19:

bjorn@nemi:~/privat/prog/git/wwan/scripts$ ./swi_setusbcomp.pl --device=/dev/cdc-wdm2 --usbcomp=19
MBIM OPEN succeeded
QMI msg '0x0021' returned status = 1
MBIM QMI support verified
supports 23 QMI subsystems:
  QMI_CTL (1.5)
  QMI_WDS (1.16)
  QMI_DMS (1.13)
  QMI_NAS (1.25)
  QMI_QOS (1.3)
  QMI_WMS (1.8)
  QMI_PDS (1.13)
  QMI_AUTH (1.2)
  QMI_AT (1.2)
  QMI_VOICE (2.1)
  QMI_CAT2 (2.11)
  QMI UIM (1.12)
  QMI PBM (1.4)
  QMI_LOC (2.0)
  QMI_SAR (1.0)
  0x12 (1.0)
  QMI_TS (1.0)
  QMI_TMD (1.0)
  QMI_WDA (1.0)
  0x1d (1.0)
  QMI_CAT (2.11)
  QMI_RMS (1.0)
  0xf0 (1.0)
QMI msg '0x0022' returned status = 1
Got QMI DMS client ID '4'
QMI msg '0x555b' returned status = 1
Current USB composition: 9
USB compositions:
   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                 NOT SUPPORTED
  14 - Config1: comp6    Config2: comp9                 SUPPORTED
  15 - Config1: comp6    Config2: comp10                NOT SUPPORTED
  16 - Config1: comp6    Config2: comp11                NOT SUPPORTED
  17 - Config1: comp6    Config2: comp12                NOT SUPPORTED
  18 - Config1: comp7    Config2: comp8                 NOT SUPPORTED
  19 - Config1: comp7    Config2: comp9                 SUPPORTED
  20 - Config1: comp7    Config2: comp10                NOT SUPPORTED
  21 - Config1: comp7    Config2: comp11                NOT SUPPORTED
  22 - Config1: comp7    Config2: comp12                NOT SUPPORTED
QMI msg '0x555c' returned status = 1
QMI msg '0x0023' returned status = 1

After resetting the modem (which the script will not do), I got a multi config device as expected:

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 18 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  2
P:  Vendor=1199 ProdID=9041 Rev= 0.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=EM7305
C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=
E:  Ad=82(I) Atr=03(Int.) MxPS=  12 Ivl=32ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=
E:  Ad=84(I) Atr=03(Int.) MxPS=  12 Ivl=32ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=10 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=11 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
C:* #Ifs= 2 Cfg#= 2 Atr=e0 MxPwr=500mA
A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Let me know if you try this. Note that the descriptions are hard coded in the script, based on the AT command output from the MC7710. I don’t know how to dynamically retrieves these. This will probably not work as expected on newer modules (MC7455 etc). But it should be easy to adapt to those if anyone is willing to debug a bit.

13

It works perfectly! :smiley: Thankyou. It was able to switch my MC7354 to composition 8 for now with no issues. It still has MBIM but at least i also have the AT, DM, and GPS ports open as well now.

Now if Microsoft would get Windows 10 to stop force switching the device composition whenever i reboot my laptop from QMI to MBIM only would be nice, but i’ve already sent a Feedback remark regarding this. There’s nothing more frustrating than working with the AT interface, in the middle of re configuring the modem, and then suddenly Windows decides that it would be a great Idea to switch it to MBIM… "-_-

14

Working for me too…

15

The solution worked for me! Thank you very much!!!

16

Another confirm that this worked to restore a MC7354 that Windows 10 put into MBIM mode. I put mine back to USB comp mode 6.

FYI on Debian (Wheezy, at least) the necessary Perl modules can be installed with:

apt-get install libuuid-tiny-perl libipc-shareable-perl libjson-perl -y

Thanks dl5162!

17

After playing with the device, switching it between a linux and windows 10 environment, I found a temporary fix that alleviated my frustration for the most part with windows switching the device to MBIM only. As it seems that the OS has a preference for MBIM, this fix will direct the OS to use USBCOMP 8 (DM, AT, NMEA, MBIM) instead of defaulting to USBCOMP 9 (MBIM) when the system finds the device with a QMI interface. (My laptop is dual booted with Linux and windows, if i forget to change my composition to 8 before switching, Windows automatically forces it to composition 9… which usually means switching back to linux, using the above fix, then booting windows again… sigh)

This fix requires a fresh install of the Sierra Wireless Drivers for your device. If you have them installed already, uninstall them and reboot your computer before continuing.

  1. Open Command Prompt as Administrator.

  2. Navigate to the directory containing GenericDriverSetup_Build4277.exe
    cd C:<Path to install file>\

  3. Run the install with the following parameter
    GenericDriverSetup_Build4277.exe WIN8BUSDriver=1 USBCOMP=8 DisableUsbCompAutoUpdate=1 GPS=1 GPSAUTO=1

  4. Finish the driver install as normal, then reboot your computer.

  5. Now you have two options at this point if your device is in USBCOMP 9. The above is not enough to automatically have the system change it to the composition you specified. So if it was in composition 9 before you did the above, it will still be in composition 9 after. To switch it, you can:

    a) Use the linux fix in the posts above to switch it to 8 then plug the device back into windows OR
    b) Update your firmware. Even if you have the most updated one. Just rerun the update tool provided by sierra wireless. Once the update is finished,
    open device manager. You should see a modem, NMEA, and DM Ports along with the MBIM network interface.

After doing the above myself, if i left the device in composition 6 (DM, NMEA, AT, QMI) and then booted windows, windows will now change it to composition 8 by default instead of composition 9.

Hope this helps anyone in the same situation as myself.

Edited October 20th 2015 - Added GPS=1 and GPSAUTO=1. Heard from other users that USBCOMP=8 was not enough sometimes but adding the extra parameters did help

*Edited October 30th 2015 - Added WIN8BUSDriver=1 and DisableUsbCompAutoUpdate=1 . After looking through my windows registry i found the Sierra Wireless software key setting in the windows registry. After using the new parameters, windows no longer tries to switch the modem out of QMI mode! :mrgreen: :smiley:
*Thanks to dl5162 for pointing out the DisableUsbCompAutoUpdate=1 setting that i overlooked :slight_smile:

For those that are interested you can find the Registry keys by opening the registry editor ( regedit from command line) and navigating to

HKEY_LOCAL_MACHINE\SOFTWARE\Sierra Wireless Inc\DriverInstallOptionsUsed

I have also modified a Configuration.ini file from the driver install package and zipped it to an archive for those that are interested to give it a try. Just unzip it in the same folder as the driver installer and run the installer. Let me know how it works for you. Currently i am running Windows 10 with the MC7354 in Composition 6 which is QMI. :slight_smile:
MBIM_DisableAutoUpdate-Fix[MC77xx_MC73xx].zip (43.6 KB)

18

The solution works perfect to me.
My modem are MC7710.
Thank you very much.
:smiley:

Ricky

19

I was wrong. The script works like a charm on the MC7455 too. And it is even more useful there, since that firmware doesn’t support the AT!UDUSBCOMP command. So having an AT serial port doesn’t help anymore.

Note that you’ll need to strip away the MBIM wrapping for the initial switch from QMI mode, if you want to test this on an MC74xx.

EDIT: Cancel that. Be careful. I seem to have messed up the AT command port using this switching method. Not recommended on the MC74xx.

EDIT2: Another update on this… Looks like a simple USB reset will fix things again. I have no idea why. But playing with the USB composition switching on MC74xx can be considered somewhat safe again. I’ve updated the perl script with support for USB reset to make that easier. Also added support for QMI mode. The script will now autodetect MBIM/QMI and wrap the commands with the correct headers regardless of mode, making it very easy to switch back and forth.

20

It is not completely true, a new command is available.
Please check with your Distributor or Sierra contact to get related AT cmd guide.
Thx