QMI via MBIM for "FCC Authentication" fix

Collin McMillan cmc at nd.edu
Wed Jul 29 14:05:42 PDT 2015


Ok great, I'll keep at it!

On Wed, Jul 29, 2015 at 4:54 PM, Bjørn Mork <bjorn at mork.no> wrote:

> Collin McMillan <cmc at nd.edu> writes:
>
> > Hi Folks
> >
> > 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.
> >
> > If I understand correctly, all I need to do is send a message like this
> one:
> >
> > 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
> >
> > Checking the spec (
> http://caxapa.ru/thumbs/334029/MBIM_v1_0_USBIF_FINAL.pdf),
> > that means:
> >
> > 03 00 00 00: MessageType, 3 for command, see table 9.1 in the above PDF
> > 40 00 00 00: MessageLength, 64 bytes
> > 04 00 00 00: TransactionID, libmbim picked this for me
> >
> > 01 00 00 00 00 00 00 00: FragmentHeader (table 9.3)
> > D1 ... D3: 16 bytes for the service UUID
> > 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)
> > 01 00 00 00: 1 for a SET operation (table 9-6 in the spec PDF)
> > 10 00 00 00: InformationBufferLength, 16 bytes
> > 01 0C...end: InformationBuffer
> >
> > Then InformationBuffer is the QMI message.  In this case, I sent:
> > 01 0C 00 00 02 01 00 01 00 5F 55 00 00
> >
> > I got this from running:
> > qmicli -d /dev/cdc-wdm0 --dms-set-fcc-authentication -v --client-cid=1
> > This command fails, but it does output the raw data sent to the device,
> > using the verbose flag.
> >
> >
> > Anyway, what I have now is:
> > 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.
> >
> >     //
> >
> *********************************************************************************
> >     { "type" : "Service",
> >       "name" : "QMI Over" },
> >
> >   //
> >
> *********************************************************************************
> >   { "name"     : "qmi",
> >     "service"  : "QMIOver",
> >     "type"     : "Command",
> >     "set"    : [ { "name"       : "QmiMsg",
> >                      "format"     : "byte-array",
> >                      "array-size" : "16" } ],
> >     "response" : [ { "name"       : "QMUX",
> >                      "format"     : "byte-array",
> >                      "array-size" : "65" } ] }
> >
> >
> > 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):
> >
> > [29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion
> > 'service > MBIM_SERVICE_INVALID' failed
> > [29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message
> > (translated)...
> >>>>>>> Header:
> >>>>>>>   length      = 72
> >>>>>>>   type        = command-done (0x80000003)
> >>>>>>>   transaction = 3
> >>>>>>> Fragment header:
> >>>>>>>   total   = 1
> >>>>>>>   current = 0
> >>>>>>> Contents:
> >>>>>>>   status error = 'None' (0x00000000)
> >>>>>>>   service      = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
> >>>>>>>   cid          = '(null)' (0x00000001)
> >
> > [29 Jul 2015, 16:06:01] [Debug] Asynchronously sending QMI test
> message...
> > [29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Sent message...
> > <<<<<< RAW:
> > <<<<<<   length = 64
> > <<<<<<   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
> >
> > [29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion
> > 'service > MBIM_SERVICE_INVALID' failed
> > [29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Sent message
> (translated)...
> > <<<<<< Header:
> > <<<<<<   length      = 64
> > <<<<<<   type        = command (0x00000003)
> > <<<<<<   transaction = 4
> > <<<<<< Fragment header:
> > <<<<<<   total   = 1
> > <<<<<<   current = 0
> > <<<<<< Contents:
> > <<<<<<   service = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
> > <<<<<<   cid     = '(null)' (0x00000001)
> > <<<<<<   type    = 'set' (0x00000001)
> >
> > [29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message...
> >>>>>>> RAW:
> >>>>>>>   length = 48
> >>>>>>>   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
> >
> > [29 Jul 2015, 16:06:01] -Error ** mbim_cid_get_printable: assertion
> > 'service > MBIM_SERVICE_INVALID' failed
> > [29 Jul 2015, 16:06:01] [Debug] [/dev/cdc-wdm0] Received message
> > (translated)...
> >>>>>>> Header:
> >>>>>>>   length      = 48
> >>>>>>>   type        = command-done (0x80000003)
> >>>>>>>   transaction = 4
> >>>>>>> Fragment header:
> >>>>>>>   total   = 1
> >>>>>>>   current = 0
> >>>>>>> Contents:
> >>>>>>>   status error = 'Failure' (0x00000002)
> >>>>>>>   service      = 'invalid' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
> >>>>>>>   cid          = '(null)' (0x00000001)
> >
> > (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)
> >
> > 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.
> >
> > 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.
> >
> >
> > Thanks again!
>
> The above looks basically fine to me.  I cannot see any obvious reason
> why it fails.  But it's an MBIM failure, so I don't think it's related
> to the actual QMI message.  There's probably some weird formatting
> thing missing.
>
> I do notice that you send a 16 byte InfoBuffer with a zero-padded 13
> byte QMI message.  Maybe that doesn't work?
>
> FWIW, here's a transaction sequence I used when I briefly tested this a
> month ago.  As you can see, I used the exact QMI message length for the
> MBIM InfoBuffer:
>
>
> MBIM OPEN:
> 01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 00
>
> MBIM OPEN_DONE:
> 01 00 00 80 10 00 00 00 01 00 00 00 00 00 00 00
>
> CTL 0x0022 request:
> 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
>
> CTL 0x0022 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 34
>
> DMS 0x555b request:
> 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 34 00 06 00 5b 55 00 00
>
> DMS 0x555b 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 2d 00 00 00 01 2c
> 00 80 02 34 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
>
> CTL 0x0023 request:
> 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 34
>
> CTL 0x0023 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 34
>
> MBIM CLOSE
> 02 00 00 00 0c 00 00 00 0a 00 00 00
>
> MBIM CLOSE_DONE
> 02 00 00 80 10 00 00 00 0a 00 00 00 00 00 00 00
>
>
>
> Bjørn
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libmbim-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20150729/16f803a8/attachment.html>


More information about the libmbim-devel mailing list