QMI via MBIM for "FCC Authentication" fix
Markus Gothe
nietzsche at lysator.liu.se
Fri Jul 31 13:14:35 PDT 2015
Dan is right,
however look at mbimd running on ZTE MF823 (with telnet enabled(!)), I was able to analys the binary enough to say that their implementation of MBIM is actually a wrapper around QMI.
Thus running QMI over MBIM over QMI is very feasable in this case.
//M
Den 31 jul 2015 5:49 em skrev Dan Williams <dcbw at redhat.com>:
>
> 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
>
> _______________________________________________
> 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