Sierra Wireless EM7305: unable to connect after suspend

Florian Klink flokli at flokli.de
Sat Jun 28 09:15:10 PDT 2014


Am 25.06.2014 18:43, schrieb Aleksander Morgado:
> On Sat, Jun 14, 2014 at 12:59 AM, Florian Klink <flokli at flokli.de> wrote:
>> 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
>>
> 
> 
> Are you sure you got the patch correctly applied? The "home->idle"
> transition here, which is done exactly 60s after the registration
> request, looks like the issue we were trying to solve with the
> patch...
> 
> ModemManager[1572]: <info>  [1402698267.202674]
> [mm-iface-modem-3gpp.c:1079]
> update_registration_reload_current_registration_info_ready(): Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (registering -> home)
> NetworkManager[1573]: <debug> [1402698318.713189]
> [nm-netlink-monitor.c:164] link_msg_handler(): netlink link message:
> iface idx 4 flags 0x1003
> ModemManager[1572]: <info>  [1402698327.211163]
> [mm-iface-modem-3gpp.c:1169] update_registration_state(): Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (home -> idle)
> 
> Also, I'm not seeing this log message:
>     g_debug ("registration check was finished via indication");
> 
> So either the patch wasn't added correctly, or the patch doesn't work
> :) Could you re-check whether you correctly added the patch?
> 

I re-checked by applying a second patch on top that issued a

> mm_dbg ("||| debug message, broadband-modem-mbim: support finishing registration requests via indications was applied");

inside modem_3gpp_run_registration_checks(...).

This message appeared in the logs once on each connection attempt, so I
must have your patch applied, too ;)

It looks like the patch doesn't work correctly.


I attached the new dump with your patch and mine applied. Seems like
some notification sms from my provider came in, I removed them from the
logs. Btw, is there any GUI support planned for displaying incoming sms?

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output2.txt.gz
Type: application/gzip
Size: 20569 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20140628/e7b95001/attachment-0001.bin>
-------------- 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/20140628/e7b95001/attachment-0001.sig>


More information about the ModemManager-devel mailing list