netdev - Re: cdc-wdm: unable to connect after suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jun 2014 17:05:03 +0200
From:	Aleksander Morgado <aleksander@...ksander.es>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Florian Klink <flokli@...kli.de>, netdev@...r.kernel.org,
	"ModemManager (development)" 
	<modemmanager-devel@...ts.freedesktop.org>
Subject: Re: cdc-wdm: unable to connect after suspend

On Wed, Jun 11, 2014 at 1:53 PM, Bjørn Mork <bjorn@...k.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?

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.

-- 
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html