Sierra Wireless vendor specific DMS messages
Bjørn Mork
bjorn at mork.no
Wed Jul 1 01:10:31 PDT 2015
Hello,
recently there has been a few reports of Sierra modems being
automatically configured for "MBIM only" by Windows8. Some Sierra
Windows application probably makes this change to avoid presenting a
mess of unsupported functions in Windows, under the assumption that a
module installed in a Windows computer will not be moved to any other
OS. Which probably is true in almost all cases.
But this does cause serious problems for users who only temporarily
plugged the module into a Windows PC, but intend to use the QMI or AT
functions of the modem. AFAIK, the only documented way to change the
USB composition setting is vendor specific AT commands. And the AT
command interface is completely disabled by Windows.
Recently I happend to notice the addition of a couple of new functions
in the DMS part of the Sierra SDK:
SLQSSwiGetUSBComp()
SLQSSwiSetUSBComp()
These functions send two vendor specific DMS messages to the modem:
0x555b and 0x555c.
Trying out 0x555b (get) on my MC7710 without any input was an immediate
success. It returned two TLVs matching the USB composition output from
the AT command interface:
0x10: current USB composition (1 byte)
0x11: (sorted?) array of supported USB compositions (1 byte length
prefix, 1 byte elements).
This is the sample run using one of my old perl scripts, as I still find
that easiest when testing out new and unknown messages. But I trust you
are able to decode it. There is a hexdump of the full QMI messages too,
as you can see:
sending to /dev/cdc-wdm1:
01 0c 00 00 02 01 00 02 00 5b 55 00 00
=> QMUX Header:
=> len: 0x000c
=> sender: 0x00
=> svc: 0x02
=> cid: 0x01
=> QMI Header:
=> Flags: 0x00
=> TXN: 0x0002
=> Cmd: 0x555b
=> Size: 0x0000
reading from /dev/cdc-wdm1
[Tue Jun 30 18:05:30 2015] read 45 bytes from /dev/cdc-wdm1
01 2c 00 80 02 01 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: 0x01
<= 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 ..................
got match!
This is matching the AT interface output, but missing the descriptions
and the list of unsupported settings. I don't know if those are
statically defined or available via some other QMI command:
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
Onto testing the 0x555c (set) message. Guessing based on the above data
format and the most common TLV numbering, that the required input TLV is
0x01: new USB composition (1 byte)
was an immediate success:
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
got match!
So, that's also a success, and the new setting can be immediately
verified in the AT command interface:
at!udusbcomp?
!UDUSBCOMP: 14
Given that there are currently multiple reports of users facing the
"MBIM only" problem, on modules like MC7710 and MC7354, I believe it
would be great to provide some way for them to use this information to
reset their modules back to some sane setting. But as usual, I don't
see that I am going to find enough time to implement it. So I send this
preliminary test info now, along with a completely untested patch for
qmi-service-dms.json, in the hope that someone else can use it. Maybe
there even are developers on this list with the same problem?
Now, what I've presented is a QMI solution and the problem is that the
modem presents only an MBIM function. Luckily there are most likely two
ways to overcome that:
1) Sierra modems are known to probe the control protocol and will
happily speak QMI if that is the first protocol the hear after
reset, even in MBIM mode
2) As I have mentioned earlier: Qualcomm based MBIM devices often have
a vendor specific MBIM services allowing them to tunnel QMI inside
MBIM
I have verified manually that the latter solution works with my MC7710.
You can request a QMI DMS client ID via the MBIM QMI service, and the
Sierra vendor specific messages are available.
This is probably more relevant for the libmbim list, but just for
completeness: The UUID of the MBIM QMI service is
'd1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3'. There is only one CID (1),
supporting set only. It takes any valid QMI packet as payload and
returns the QMI response packet in the MBIM return payload (aka
'InformationBuffer'). So it is in effect only a standard MBIM header
prepended to QMI.
I believe support for this MBIM vendor sepcific service would be
generally extremely useful, but I've not yet been able to make up my
mind how it should be modelled within the libqmi/libmbim framework..
Bjørn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dms-add-vendor-specific-USB-composition-messages.patch
Type: text/x-diff
Size: 2587 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150701/72c15464/attachment.patch>
More information about the libqmi-devel
mailing list