Comment 2 for bug 1440917

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.10.0-4ubuntu19

---------------
network-manager (0.9.10.0-4ubuntu19) wily; urgency=medium

  [ Tony Espy ]
  * debian/patches/add_ofono_settings_support.patch: remove code
    that added APN, USERNAME and PASSWORD to NM_SETTING_GSM object.
    NM doesn't actually need access to these settings, and USERNAME/
    PASSWORD can cause issues with NM's secrets needed logic.
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1461593-add-nm-settings-connection-reset-retries-methods.patch,
    debian/patches/add_ofono_settings_support.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: More changes
    to NMModemOfono's modem_state handling. Added get/set_reset_retries_timeout
    methods to NMSettingsConnection, and use the set method to lower the timeout for
    ofono connections to 30s. Finally added a 5s delay to NM_POLICY's activation
    logic triggered when a modem device is disconnected. This allows modem time to
    settle and NM to process the resulting DBus state changes. (LP: #1461593)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1445080-modify-device-modem-avail.patch,
    debian/patches/lp1445080-nm-modem-check-for-set-mm-enabled-func.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: These
    changes collectively fix flight-mode on arale ( and other devices ), due to
    some fundemental race conditions in the ofono logic. (LP: #1445080, #1440917)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/add_ofono_settings_support.patch: Add support for the ofono
    gprs-context 'Preferred' property. (LP: #1361864)

  [ Mathieu Trudel-Lapierre ]
  * d/p/0002-wifi-cull-the-scan-list-before-signalling-ScanDone-b.patch:
    Re-add schedule_scan() call after we get the ScanDone signal from the
    supplicant. Otherwise we'd do one scan on startup and never scan again.
    (LP: #1445134)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 05 Aug 2015 12:17:28 -0400