Sierra Wireless vendor specific DMS messages
Markus Gothe
nietzsche at lysator.liu.se
Wed Jul 1 11:36:32 PDT 2015
The vendor specific one is interesting... Might be AT-commands with encapsulation like Huawei does it.
Is it necessary tied with DMS?
Maybe an upgrade path for fw???
Which version of the SDK is this from? I was looking for USSD-support in an old version of their SDK.
//M
Den 1 jul 2015 10:10 fm skrev Bjørn Mork <bjorn at mork.no>:
>
> 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
>
> From 56783ed522323a3ced13402aea9acd59e20fc227 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn at mork.no>
> Date: Wed, 1 Jul 2015 10:09:59 +0200
> Subject: [PATCH] dms: add vendor specific USB composition messages
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Bjørn Mork <bjorn at mork.no>
> ---
> data/qmi-service-dms.json | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/data/qmi-service-dms.json b/data/qmi-service-dms.json
> index 706c41a..250cbdf 100644
> --- a/data/qmi-service-dms.json
> +++ b/data/qmi-service-dms.json
> @@ -1188,6 +1188,41 @@
> "prerequisites" : [ { "common-ref" : "Success" } ] } ] },
>
> // *********************************************************************************
> + { "name" : "Get USB Composition",
> + "type" : "Message",
> + "service" : "DMS",
> + "id" : "0x555B",
> + "version" : "1.0",
> + "output" : [ { "common-ref" : "Operation Result" },
> + { "name" : "Composition",
> + "id" : "0x10",
> + "mandatory" : "yes",
> + "type" : "TLV",
> + "format" : "guint8",
> + "prerequisites" : [ { "common-ref" : "Success" } ] },
> + { "name" : "Supported",
> + "id" : "0x11",
> + "mandatory" : "no",
> + "type" : "TLV",
> + "format" : "array",
> + "size-prefix-format" : "guint8",
> + "array-element" : { "format" : "guint8" },
> + "prerequisites" : [ { "common-ref" : "Success" } ] } ] },
> +
> + // *********************************************************************************
> + { "name" : "Set USB Composition",
> + "type" : "Message",
> + "service" : "DMS",
> + "id" : "0x555C",
> + "version" : "1.0",
> + "input" : [ { "name" : "Composition",
> + "id" : "0x01",
> + "mandatory" : "yes",
> + "type" : "TLV",
> + "format" : "guint8" } ],
> + "output" : [ { "common-ref" : "Operation Result" } ] },
> +
> + // *********************************************************************************
> { "name" : "Set FCC Authentication",
> "type" : "Message",
> "service" : "DMS",
> --
> 2.1.4
>
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
More information about the libqmi-devel
mailing list