QMI via MBIM for "FCC Authentication" fix
Collin McMillan
cmc at nd.edu
Thu Jul 30 13:05:59 PDT 2015
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
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20150730/54011258/attachment-0001.html>
More information about the libmbim-devel
mailing list