QMI via MBIM for "FCC Authentication" fix
Dan Williams
dcbw at redhat.com
Fri Jul 31 08:49:07 PDT 2015
On Thu, 2015-07-30 at 16:05 -0400, Collin McMillan wrote:
> Continuing this thread... :-)
>
> It turns out that I was not actually using the CID allocated during the CTL
> request. That much was easy enough to fix. The "03" at the CTL 0x0022
> response needed to be in the DMS 0x555b request. My complete transaction
> sequence is at the bottom.
>
> The short version is that it *does* look like I can access the
> QMI-over-MBIM interface this way. However, I am getting a weird reply on
> the 0x555b response. The power state is still low after I do this.
>
> The only major difference between Bjorn's sequence and mine is the 0x555b
> response. His was:
>
> 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
>
> Mine was
>
> 03 00 00 80 56 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 26 00 00 00 01 25
> 00 80 02 03 02 06 00 5B 55 19 00 02 04 00 00 00 00 00 10 01 00 0E 11 0B 00
> 0A 01 06 07 08 09 0A 0B 0C 0E 13
>
> Without a QMI spec it is rather hard to decode this (why is it so hard to
> find btw), so I need to feed it through libqmi. Unless there are any more
Because QMI is a Qualcomm proprietary protocol and you need to ask them
to see the specification, and likely pay them some money to get into
their developer program. This hardware and QMI are in no way "open",
and we've only been able to support them by reverse engineering and
publicly available code and documentation that Qualcomm and others have
actually released (like GobiAPI, the Google-released rmnet drivers,
etc).
Dan
> clues here on the list?
>
> I may also try to monitor the USB device in Windows, to see what is being
> sent to the device anyway. I wonder if there is some other command that I
> am missing. Or perhaps the drivers from Lenovo are locking the card
> somehow.
>
>
>
> 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 03
>
> 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 03 00 06 00 5b 55 00 00
>
> DMS 0x555b response
> 03 00 00 80 56 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 26 00 00 00 01 25
> 00 80 02 03 02 06 00 5B 55 19 00 02 04 00 00 00 00 00 10 01 00 0E 11 0B 00
> 0A 01 06 07 08 09 0A 0B 0C 0E 13
>
> 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 03
>
> 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 03
>
> 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
>
>
> 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
> >
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libmbim-devel
More information about the libmbim-devel
mailing list