QMI via MBIM for "FCC Authentication" fix
Collin McMillan
cmc at nd.edu
Thu Jul 30 13:43:41 PDT 2015
Wait, hold that thought. I made a silly mistake! I was sending 0x555B,
when it should be 0x555F. Relevant part of the new transaction log:
Sent to modem 0x555F 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 14 00 01 00 5F 55 00 00
Response recieved from modem
03 00 00 80 44 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 14 00 00 00 01 13
00 80 02 14 02 01 00 5F 55 07 00 02 04 00 00 00 00 00
After this, it is necessary to reset the device (software detach and
reattach via USB authorized flag worked fine). Then, I am able to
connect! Finally!
I will clean up my code and make a utility available for anyone else having
this problem. Then I'll work on integrating it into libqmi to create a
"MBIM layer" for QMI commands.
Collin
On Thu, Jul 30, 2015 at 4:05 PM, Collin McMillan <cmc at nd.edu> 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
> 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/27d40f9f/attachment-0001.html>
More information about the libmbim-devel
mailing list