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

IoT Modules MC/EM Series
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

21

Thanks! When you mention it, I even believe I saw something about that on this forum…

The truth is that I am now so spoiled with the excellent “source” site that I thought I’d just wait for the documents to appear there, instead of unnecessarily “bothering” my Sierra contact. But I guess I should request a documentation set. I feel a bit like I did with the MC7710 in 2012 though: It is very difficult to know what to ask for without knowing exactly which documents are available. It’s a bit better now though, as I guess I can assume there are updated versions of most of the documents relevant to the MC73xx series.

And just for the record: I like very much what I’ve seen of the MC7455 so far. I really appreciate small improvements like (finally) adding a CDC Union descriptor to the MBIM function. And the support for multiple MBIM IP sessions now makes MBIM a viable alternative to QMI for these modules. Personally I’d like to see a move towards MBIM for embedded usage too. But I understand that both Sierra and your customers are locked into existing software solutions, making both QMI and AT commands necessary. Still hoping that we’ll see more MBIM in embedded as soon as assorted BSPs start using v3.8 or newer kernels. I haven’t actually tested it, but I see no reason why an MC7455 released in the 2nd half of 2015 shouldn’t work out-of-the-box with the mainline cdc_mbim driver released in February 2013. No need for any device ID addition or anything. That in itself should be all the reasons you need for MBIM, IMHO.

But as usual, I am biased :slight_smile:

22

Hi, any advice on getting this working in Arch Arm linux?

Can’t locate UUID/Tiny.pm in @INC (you may need to install the UUID::Tiny module) (@INC contains: /usr/lib/perl5/5.36/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.36/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.36/core_perl /usr/share/perl5/core_perl) at ./swi_setupcomp.pl line 8.

23

A lot has happened in the 7+ years since that was written. So, while it still is possible to use the hackish perl script, I recommend using libqmi/qmicli instead.

The get/set-usb-composition commands do exactly the same as the perl script:

bjorn@miraculix:~$ qmicli --help-dms|grep swi
  --dms-swi-get-current-firmware                                                                                    Get Current Firmware (Sierra Wireless specific)
  --dms-swi-get-usb-composition                                                                                     Get current and supported USB compositions (Sierra Wireless specific)
  --dms-swi-set-usb-composition=[#]                                                                                 Set USB composition (Sierra Wireless specific)

qmicli can also be used in MBIM mode.

I assume libqmi is packaged for Arch Linux as well. In Debian, the package with qmicli is named libqmi-utils. It’s probably something similar in other Linux distros.

24

Well the issue I am having is that I am unable to send text msgs, it was suggested that I change this to QMI but I have been using it using mmcli and still getting sms msg blocking.

I do have qmicli installed but do not know how this works compared to mmcli

25

I don’t think MBIM or QMI will affect messaging capabilities. That’s just different protocols use to talk to the modem from the host. It doesn’t change how the modem communicates with the network.

26

I am facing similar issue like posted here:

However on my system I don’t have any /dev/cdc-wdm* device available, so qmicli cannot really talk to the modem:

# ls -l /dev/cdc-wdm0
ls: cannot access '/dev/cdc-wdm0': No such file or directory

# modprobe cdc_mbim
# dmesg -T
...
[Thu Apr 13 07:08:43 2023] usbcore: registered new interface driver cdc_ether
[Thu Apr 13 07:08:43 2023] usbcore: registered new interface driver cdc_ncm
[Thu Apr 13 07:08:43 2023] usbcore: registered new interface driver cdc_wdm
[Thu Apr 13 07:08:43 2023] usbcore: registered new interface driver cdc_mbim

# ls -l /dev/cdc-wdm*
ls: cannot access '/dev/cdc-wdm*': No such file or directory
27

Same goes when I load qmi_wwan and qmi_helpers, no /dev/cdc-wdm* device pops up. Not sure how I can switch the modem to !UDUSBCOMP: 6 without access to /dev/cdc-wdm0