<div dir="ltr"><div><div><div>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 </div>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! </div>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. </div>Collin </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jul 30, 2015 at 4:05 PM, Collin McMillan <<a href="mailto:cmc@nd.edu" target="_blank">cmc@nd.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Continuing this thread... :-) </div>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. </div><div>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. </div><div>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 </div><div>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 </div><div>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? </div><div>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. </div><div> </div><div> 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 </div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jul 29, 2015 at 4:54 PM, Bjørn Mork <<a href="mailto:bjorn@mork.no" target="_blank">bjorn@mork.no</a>> wrote: <div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Collin McMillan <<a href="mailto:cmc@nd.edu" target="_blank">cmc@nd.edu</a>> 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 (<a href="http://caxapa.ru/thumbs/334029/MBIM_v1_0_USBIF_FINAL.pdf" rel="noreferrer" target="_blank">http://caxapa.ru/thumbs/334029/MBIM_v1_0_USBIF_FINAL.pdf</a>), > 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! </div></div>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 <div><div>_______________________________________________ libmbim-devel mailing list <a href="mailto:libmbim-devel@lists.freedesktop.org" target="_blank">libmbim-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libmbim-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libmbim-devel</a> </div></div></blockquote></div></div></div> </div> </blockquote></div> </div>