When the Ericsson F5321 with firmware R3C11/R4D04 is told to make
an IPv6-only connection, it reports that it has IPv4 configuration
but then returns no actual addresses. Check both the flags and
actual data before trying to use them.
ModemManager[25850]: <debug> [1506958721.914717] IPv4 configuration available: 'address, gateway, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914731] IP addresses (0)
ModemManager[25850]: <debug> [1506958721.914741] DNS addresses (0)
ModemManager[25850]: <debug> [1506958721.914748] MTU: '0'
ModemManager[25850]: <debug> [1506958721.914758] IPv6 configuration available: 'address, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914767] IP addresses (1)
ModemManager[25850]: <debug> [1506958721.914852] IP [0]: 'fe80::39:f622:7d01/64'
ModemManager[25850]: <debug> [1506958721.914866] DNS addresses (2)
ModemManager[25850]: <debug> [1506958721.914883] DNS [0]: 'fd00:976a::9'
ModemManager[25850]: <debug> [1506958721.914896] MTU: '1500'
ModemManager[25850]: <debug> [1506958721.914947] (wwp0s20u1i6): port now connected
The returned list contains full references, so make sure we unref them
before going on. Note that it's ok to return a pointer to one object
inside this list even if we're unref-ing them all, because we're sure
that the caller knows it's peek-ing a port object.
All the steps in the connect_3gpp() sequence are implemented as
methods in the MMBroadbandBearer class, and therefore the objects
received in the corresponding ready() methods are all bearers, not
modems.
This issue wasn't found before because the objects received were not
really being used after all, as we were relying on the ones kept in
the context or lately in the GTask itself.
This patch implements hardware revision loading in MMBroadbandModemMbim
by extracting the HardwareInfo field from the response to a
MBIM_CID_DEVICE_CAPS query.
This patches fixes commit 334273979 "broadband-modem-mbim: preserve
unlock retries for PIN1 when appropriate", which doesn't correctly
propagate the unlock retries information for PIN1 observed from
responses to MBIM_CID_PIN set operations (see commit eb9ec1b61
"sim-mbim: update unlock retries information after PIN operations").
This patch adds a mm_iface_modem_get_unlock_retries helper for getting
the current MMUnlockRetries value of a MMIfaceModem object, which later
allows us to partially update (e.g. a specific MMModemLock) the
MMUnlockRetries value of a MMIfaceModem object.
The return status of mm_base_modem_at_command_finish() already
specifies whether an error has happened or not, so skip creating the
GError if we don't care about the actual error details.
