Sierra Wireless EM7305: unable to connect after suspend

[Florian Klink]

Am 14.06.2014 00:59, schrieb Florian Klink:
> Am 13.06.2014 16:19, schrieb Aleksander Morgado:
>> On Fri, Jun 13, 2014 at 3:56 PM, Aleksander Morgado
>> <aleksander at aleksander.es> wrote:
>>> On Thu, Jun 12, 2014 at 10:10 PM, Florian Klink <flokli at flokli.de> wrote:
>>>>> Well, I guess we should try to detect the indication and if so, use it
>>>>> as 'reply' to the request we sent. Luckily both the indication and the
>>>>> response will have the same info:
>>>>>
>>>>>     imbim_message_register_state_notification_parse (
>>>>>             notification,
>>>>>             NULL, /* nw_error */
>>>>>             &register_state,
>>>>>             NULL, /* register_mode */
>>>>>             &available_data_classes,
>>>>>             NULL, /* current_cellular_class */
>>>>>             &provider_id,
>>>>>             &provider_name,
>>>>>             NULL, /* roaming_text */
>>>>>             NULL, /* registration_flag */
>>>>>             NULL)
>>>>>
>>>>>         mbim_message_register_state_response_parse (
>>>>>             response,
>>>>>             NULL, /* nw_error */
>>>>>             &register_state,
>>>>>             NULL, /* register_mode */
>>>>>             &available_data_classes,
>>>>>             NULL, /* current_cellular_class */
>>>>>             &provider_id,
>>>>>             &provider_name,
>>>>>             NULL, /* roaming_text */
>>>>>             NULL, /* registration_flag */
>>>>>             NULL)
>>>>>
>>>>> Ugly hack, but I guess there's no other way to handle this firmware issue?
>>>>
>>>>
>>>> I'd think this approach at least seems to be less error-prone than the
>>>> one suggested below. Can you provide me a patch that treats the
>>>> indication as a reply?
>>>> I never touched libmbim, but I'd happily test a patch :-)
>>>
>>> The patch should go into ModemManager, but yes, I'll try to write one
>>> for you to test.
>>
>>
>> Attached is a (n untested!) ModemManager patch to try to handle this
>> issue, please test.
>>
>> Pretty ugly approach, but if that is the only way to handle the
>> registration checks.... :/
> 
> I tried the patch (compiled modemmanager and libmm-glib from git with
> patch applied and git libmbim).
> 
> It does not yet connect, but the output looks slightly different. I
> don't know if thats caused by the patch, or just coincidence / random
> radio waves ;-)
> 
> After receiving the unsolicited status indication, 3GPP Registration
> state changes from searching -> idle (before, it was home -> idle).
> 
> I also now see "[nm-netlink-monitor.c:164] link_msg_handler(): netlink
> link message: iface idx 4 flags 0x1003" sometimes in between the debug log.
> 
> I attached the debug output. One minute later, I tried to connect again
> (with no suspend/resume cycle in between, and the unsolicited status
> indication received had a length of 116 (the ones before had a length of
> 64). Does that make sense? I also attached this part of the debug output.
> 
> Florian
> 

Can I assist you further with this bug?

Will the patch "libmbim-glib: print parsed packet even for unmatched
transaction", now in libmbim git, help debug this problem?

Do you want me to create a new debug log? With or without the patch
"broadband-modem-mbim: support finishing registration requests
 via indications"?

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20140624/7ad4924c/attachment.sig>