Re: cdc-wdm: unable to connect after suspend

[Florian Klink <flokli@flokli.de>]

[-- Attachment #1: Type: text/plain, Size: 5348 bytes --]

Am 11.06.2014 17:05, schrieb Aleksander Morgado:
> On Wed, Jun 11, 2014 at 1:53 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> ModemManager[1861]: <info>  [1402484754.484416] [mm-iface-modem-3gpp.c:1167] update_registration_state(): Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (home -> idle)
>> ModemManager[1861]: <info>  [1402484754.484496] [mm-iface-modem-location.c:293] notify_3gpp_location_update(): Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '0', MNC: '0', Location area code: '0', Cell ID: '0')
>> ModemManager[1861]: <debug> [1402484754.484540] [mm-bearer.c:261] modem_3gpp_registration_state_changed(): Bearer not allowed to connect, not registered in 3GPP network
>> ModemManager[1861]: <info>  [1402484754.484570] [mm-iface-modem.c:894] mm_iface_modem_update_access_technologies(): Modem /org/freedesktop/ModemManager1/Modem/0: access technology changed (umts, hsdpa, hsupa -> unknown)
>> NetworkManager[1862]: <warn> (cdc-wdm1) failed to connect modem: Network timeout
>> NetworkManager[1862]: <info> (cdc-wdm1): device state change: prepare -> failed (reason 'gsm-registration-timeout') [40 120 32]
>> NetworkManager[1862]: <info> NetworkManager state is now DISCONNECTED
>> NetworkManager[1862]: <debug> [1402484754.485784] [nm-manager.c:4165] policy_activating_device_changed(): ActivatingConnection now (none)
>> NetworkManager[1862]: <warn> Activation (cdc-wdm1) failed for connection 'FONIC Vorgabe'
>> NetworkManager[1862]: <debug> [1402484754.485885] [nm-device.c:5261] nm_device_queue_state(): (cdc-wdm1): queued state change to disconnected (id 431)
>> NetworkManager[1862]: <debug> [1402484754.486259] [nm-device.c:5219] queued_set_state(): (cdc-wdm1): running queued state change to disconnected (id 431)
>> NetworkManager[1862]: <info> (cdc-wdm1): device state change: failed -> disconnected (reason 'none') [120 30 0]
>> NetworkManager[1862]: <info> (cdc-wdm1): deactivating device (reason 'none') [0]
>> NetworkManager[1862]: <debug> [1402484754.486360] [nm-firewall-manager.c:166] nm_firewall_manager_remove_from_zone(): (cdc-wdm1) firewall zone remove skipped (not running)
>> NetworkManager[1862]: <debug> [1402484754.486649] [nm-dns-manager.c:995] nm_dns_manager_begin_updates(): (update_routing_and_dns): queueing DNS updates (1)
>> NetworkManager[1862]: <debug> [1402484754.486718] [nm-dns-manager.c:1013] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration did not change
>> NetworkManager[1862]: <debug> [1402484754.486745] [nm-dns-manager.c:1017] nm_dns_manager_end_updates(): (update_routing_and_dns): no DNS changes to commit (0)
>>
>>
>>
>> But there are no MBIM messages explaining why MM sets the state to
>> 'idle'.  Is this because of the missing reply, Alexander?  Why don't we
>> just trust the (more current) result from the indication?  We do know
>> that the modem is registered to the home network here, or?
> 
> Gah....
> 
> Yeah, that's the thing:
> 
> static void
> register_in_network_context_failed (RegisterInNetworkContext *ctx,
>                                     GError *error)
> {
>     mm_iface_modem_3gpp_update_cs_registration_state (ctx->self,
> MM_MODEM_3GPP_REGISTRATION_STATE_IDLE);
>     mm_iface_modem_3gpp_update_ps_registration_state (ctx->self,
> MM_MODEM_3GPP_REGISTRATION_STATE_IDLE);
>     mm_iface_modem_3gpp_update_eps_registration_state (ctx->self,
> MM_MODEM_3GPP_REGISTRATION_STATE_IDLE);
>     mm_iface_modem_3gpp_update_access_technologies (ctx->self,
> MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN);
>     mm_iface_modem_3gpp_update_location (ctx->self, 0, 0);
> 
>     g_simple_async_result_take_error (ctx->result, error);
> }
> 
> 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 :-)


Florian


> Another option would be to avoid moving the state to IDLE when
> registration check fails, but that's pretty generic in every flow for
> every modem, not sure if we should touch that.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]