<div dir="ltr">Hi Aleksander,<div>                       Do you still need me to retest with the latest libmbim from git master for new log ?</div><div>                       I have no idea why the modem received the messages out of sequence.</div><div>                       But this issue will not happen without using mbim-proxy.</div><div>                       Do you need the log  without using mbim-proxy ?</div><div>Thanks,</div><div>Edward</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 4:58 PM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey<br>
<br>
><br>
> >> You may have hitted a bug in the proxy! I don't think anyone ever<br>
> >> tried to send MBIM requests that wouldn't fit in a single fragment.<br>
> >> Could you send us a full mbim-proxy verbose log while this command is<br>
> >> being run? You'll need to run the proxy manually with --verbose<br>
> >> *before* MM is started.<br>
><br>
> Yes, I can see how only the first fragment has valid contents. The 2nd<br>
> fragment and following ones are invalid.<br>
><br>
><br>
> [17  九  2020, 08:22:52] -Error ** mbim_cid_get_printable: assertion<br>
> 'cid > 0' failed<br>
> [17  九  2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Sent message (translated)...<br>
> <<<<<< Header:<br>
> <<<<<<   length      = 4096<br>
> <<<<<<   type        = command (0x00000003)<br>
> <<<<<<   transaction = 5<br>
> <<<<<< Fragment header:<br>
> <<<<<<   total   = 65<br>
> <<<<<<   current = 1<br>
> <<<<<< Contents:<br>
> <<<<<<   service = 'invalid' (00000000-0000-0000-0000-000000000000)<br>
> <<<<<<   cid     = '(null)' (0x00000000)<br>
> <<<<<<   type    = 'query' (0x00000000)<br>
><br>
<br>
Wait, that issue above with the invalid contents in the 2nd fragment<br>
is not an issue; that problem with the invalid prints is in<br>
libmbim-glib because we shouldn't expect service/cid/type in any other<br>
fragment than the 1st one.<br>
<br>
> Would you be able to retest but using libmbim from git master, that<br>
> has improved debug logs?<br>
<br>
This retest with the newest debug logs wouldn't harm really.<br>
<br>
><br>
> At this point, and looking at your specific setup (with MBIM over PCIe<br>
> I'm assuming?) I don't know at which point the message splitting into<br>
> fragments is being done (if at your app level or at proxy level)<br>
><br>
<br>
I no longer think the data splitting is the problem.<br>
<br>
Looking down in the logs I can see how the proxy ends up sending all<br>
fragments one after the other very quickly, before even the modem has<br>
a chance to reply back. We send the first 15 out of 65 fragments one<br>
after the other, in sequence. But it looks like the modem receives<br>
them in the wrong order?<br>
<br>
The modem complains about transaction 5 giving a fragment out of sequence:<br>
[17  九  2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Received message<br>
(translated)...<br>
>>>>>> Header:<br>
>>>>>>   length      = 16<br>
>>>>>>   type        = function-error (0x80000004)<br>
>>>>>>   transaction = 5<br>
>>>>>> Contents:<br>
>>>>>>   error = 'FragmentOutOfSequence' (0x00000002)<br>
<br>
And AFTER that we receive transaction 4 also reporting out of sequence:<br>
[17  九  2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Received message<br>
(translated)...<br>
>>>>>> Header:<br>
>>>>>>   length      = 16<br>
>>>>>>   type        = function-error (0x80000004)<br>
>>>>>>   transaction = 4<br>
>>>>>> Contents:<br>
>>>>>>   error = 'FragmentOutOfSequence' (0x00000002)<br>
<br>
Why does the modem receive the messages out of sequence? Our logs show<br>
that they are being sent in the correct order.<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>