<div dir="ltr"><div>Hi Folks<br><br></div><div>I have been continuing to look at this -- it's a really interesting problem and library!  Before I dive into libqmi, I'm trying to make it work for a specific case in libmbim.  I'm just trying to make a program that sends QMI messages to the QMI-over-MBIM service.<br><br></div><div>If I understand correctly, all I need to do is send a message like this one:<br><br>03 00 00 00 40 00 00 00 04 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 0C 00 00 02 01 00 01 00 5F 55 00 00 00 00 00<br><br></div><div>Checking the spec (<a href="http://caxapa.ru/thumbs/334029/MBIM_v1_0_USBIF_FINAL.pdf">http://caxapa.ru/thumbs/334029/MBIM_v1_0_USBIF_FINAL.pdf</a>), that means:<br><br></div><div>03 00 00 00: MessageType, 3 for command, see table 9.1 in the above PDF<br></div><div>40 00 00 00: MessageLength, 64 bytes<br></div><div>04 00 00 00: TransactionID, libmbim picked this for me<br><br></div><div>01 00 00 00 00 00 00 00: FragmentHeader (table 9.3)<br></div><div>D1 ... D3: 16 bytes for the service UUID<br></div><div>01 00 00 00: CID, I believe this has to be 1 because 1 is the only CID listed as possible on this service (see my output of mbimcli -d /dev/cdc-wdm0 --query-device-services in an above email)<br></div><div>01 00 00 00: 1 for a SET operation (table 9-6 in the spec PDF)<br></div><div>10 00 00 00: InformationBufferLength, 16 bytes<br></div><div>01 0C...end: InformationBuffer<br><br></div><div>Then InformationBuffer is the QMI message.  In this case, I sent:<br>01 0C 00 00 02 01 00 01 00 5F 55 00 00<br></div><div><br></div><div>I got this from running:<br>qmicli -d /dev/cdc-wdm0 --dms-set-fcc-authentication -v --client-cid=1<br></div><div>This command fails, but it does output the raw data sent to the device, using the verbose flag.<br><br><br></div><div>Anyway, what I have now is:<br></div><div>1) A modified version of libmbim 1.12.2 that includes a new service called QMIOVER.  I can send all the gory details, but essentially it is just a new data/json service file, and several appropriate changes to libmbim e.g. to mbim-cid.h/c and mbim-uuid.h/.c.<br><br>    // *********************************************************************************<br>    { "type" : "Service",<br>      "name" : "QMI Over" },<br><br>  // *********************************************************************************<br>  { "name"     : "qmi",<br>    "service"  : "QMIOver",<br>    "type"     : "Command",<br>    "set"    : [ { "name"       : "QmiMsg",<br>                     "format"     : "byte-array",<br>                     "array-size" : "16" } ],<br>    "response" : [ { "name"       : "QMUX",<br>                     "format"     : "byte-array",<br>                     "array-size" : "65" } ] }<br><br><br></div><div>2) A pretty ugly stripped down version of mbimcli, that just opens the device, tries to send a QMI allocate CID message, then the FCC message, and the closes the device.  Here's the relevant output of that program (same a mbimcli's verbose output):<br><br>[29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion 'service > MBIM_SERVICE_INVALID' failed<br>[29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message (translated)...<br>>>>>>> Header:<br>>>>>>>   length      = 72<br>>>>>>>   type        = command-done (0x80000003)<br>>>>>>>   transaction = 3<br>>>>>>> Fragment header:<br>>>>>>>   total   = 1<br>>>>>>>   current = 0<br>>>>>>> Contents:<br>>>>>>>   status error = 'None' (0x00000000)<br>>>>>>>   service      = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)<br>>>>>>>   cid          = '(null)' (0x00000001)<br><br>[29 Jul 2015, 16:06:01] [Debug] Asynchronously sending QMI test message...<br>[29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Sent message...<br><<<<<< RAW:<br><<<<<<   length = 64<br><<<<<<   data   = 03:00:00:00:40:00:00:00:04: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:0C:00:00:02:01:00:01:00:5F:55:00:00:00:00:00<br><br>[29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion 'service > MBIM_SERVICE_INVALID' failed<br>[29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Sent message (translated)...<br><<<<<< Header:<br><<<<<<   length      = 64<br><<<<<<   type        = command (0x00000003)<br><<<<<<   transaction = 4<br><<<<<< Fragment header:<br><<<<<<   total   = 1<br><<<<<<   current = 0<br><<<<<< Contents:<br><<<<<<   service = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)<br><<<<<<   cid     = '(null)' (0x00000001)<br><<<<<<   type    = 'set' (0x00000001)<br><br>[29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message...<br>>>>>>> RAW:<br>>>>>>>   length = 48<br>>>>>>>   data   = 03:00:00:80:30:00:00:00:04: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:02:00:00:00:00:00:00:00<br><br>[29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion 'service > MBIM_SERVICE_INVALID' failed<br>[29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message (translated)...<br>>>>>>> Header:<br>>>>>>>   length      = 48<br>>>>>>>   type        = command-done (0x80000003)<br>>>>>>>   transaction = 4<br>>>>>>> Fragment header:<br>>>>>>>   total   = 1<br>>>>>>>   current = 0<br>>>>>>> Contents:<br>>>>>>>   status error = 'Failure' (0x00000002)<br>>>>>>>   service      = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)<br>>>>>>>   cid          = '(null)' (0x00000001)<br><br></div><div>(BTW, I am not sure why the mbim_cid_get_printable function gives an error here -- I have added the service macros, etc., everywhere I can find)<br></div><div><br></div><div>Yes, this is a serious hack job at this point, but I am wondering if you could tell me if I'm on the right track here. :-)  It seems that I *can* communicate with the QMI interface, but that the FCC message is failing for some reason.  It could be that I am allocating the CID improperly, or that the FCC message is improperly formatted, or that I am missing some other step.<br><br></div><div>Once I wrap my mind completely around the problem, I'm going take your suggestion and combine it with libqmi.  Then, modify qmicli so that I can run arbitrary QMI commands over MBIM.<br><br></div><div><br></div><div>Thanks again!<br><br></div><div>Collin<br><br></div><div><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 27, 2015 at 2:57 AM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jul 25, 2015 at 12:55 AM, Collin McMillan <<a href="mailto:cmc@nd.edu">cmc@nd.edu</a>> wrote:<br>
><br>
> I have also read reports of some of these modems not supporting QMI, only<br>
> MBIM.  I do have the latest firmware from Sierra.<br>
><br>
> SO, I am now trying to get the QMI over MBIM procedure going, which is<br>
> rumored to exist. :-)<br>
> <a href="http://lists.freedesktop.org/archives/modemmanager-devel/2015-July/002087.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/modemmanager-devel/2015-July/002087.html</a><br>
><br>
</span><span class="">> Apparently it is straight forward once you know what to do -- just send a<br>
> QMI message to MBIM service d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3.  I can<br>
> verify that my modem has this service with:<br>
> mbimcli -d /dev/cdc-wdm0 --query-device-services<br>
><br>
> This is where I am stuck.  I suppose this is not possible with mbimcli, so I<br>
> am trying to write a utility using libmbim to send the QMI FCC auth command<br>
> through MBIM.  Once I figure that out I am looking at adding that<br>
> functionality to mbimcli.<br>
><br>
> Would anyone on the list have a few more clues?  Specifically, do I need to<br>
> create the QMI command to wrap in libqmi first, or can it be done manually?<br>
> Is there a simplified/minimized API usage example somewhere for sending MBIM<br>
> commands?  If not, mbimcli's code will do. :-)<br>
<br>
</span>Sending a message through an MbimDevice is just about calling<br>
mbim_device_command() and getting the response with<br>
mbim_device_command_finish(); mbimcli is full of examples for that.<br>
<br>
The issue you have here is that QMI is not as easy; i.e. in order to<br>
send the QMI DMS Set FCC Auth command you first need to allocate a DMS<br>
client using the CTL service; then use the allocated DMS client ID in<br>
the QMI DMS Set FCC Auth command, and then release the DMS client<br>
using the CTL service again. I'm not sure if all these steps are<br>
required when using QMI over MBIM, but I'd assume that's the case. And<br>
the problem here is that all those steps (allocating DMS client,<br>
building and sending DMS Set FCC Auth, releasing DMS client) are done<br>
internally in libqmi. Otherwise, you'll need to use the raw QMI<br>
message API to build those messages:<br>
<a href="http://www.freedesktop.org/software/libqmi/libqmi-glib/1.12.0/libqmi-glib-QmiMessage.html" rel="noreferrer" target="_blank">http://www.freedesktop.org/software/libqmi/libqmi-glib/1.12.0/libqmi-glib-QmiMessage.html</a><br>
<br>
Anyway, if I were to do it, I'd instead try to mix both libqmi and<br>
libmbim. E.g. Create a MbimDevice, which will take care of sending the<br>
MBIM messages and receiving responses. But then also create a<br>
QmiDevice, and pass the MbimDevice as 'transport' to the QmiDevice<br>
somehow. Then you would be able to use the QmiDevice transparently,<br>
using the underlying MbimDevice. This would require libqmi to depend<br>
on libmbim, but we could do it conditional with a configure switch, I<br>
don't think it's a big deal.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div></div>