If the modem is currently disabling, we need to wait to get fully disabled
before starting with the new connection sequence.
If the modem is currently disconnecting, we need to wait to get fully
disconnected before starting with the new connection sequence.
The interfaces usually retrieve objects (e.g. skeletons) from the Modem object
using g_object_get(), but we didn't make sure that these objects were actually
valid before using them.
This should clean up errors happening when the modem gets unplugged and still
some actions are ongoing.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=685933
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
Modems have a maximum of bearers allowed to be connected at a time, number which
is given by the number of available ports that may be used for data connections.
When Simple.Connect() tries to launch a connection, it will try to find first an
existing bearer with the required parameters (e.g. APN, IP type). If such bearer
is found, it will just use it. If no such bearer is found, it will try to create
one. When trying to create one, if there is no more room for bearers in the
modem, we will remove the first disconnected bearer that we find, if any, before
trying to create the new one. This logic now makes sure that no connected bearer
gets removed in order to create a new one, and also that only one existing gets
removed if possible (not every bearer as we did previously).
Further logic to connect multiple bearers at a time cannot be done using the
Simple interface.
When bands or allowed modes are changed, the modem will very likely reset its
current registration and start from scratch. We will now give it some seconds
to settle down before going on with the connection request, so that the modem
has enough time to report being unregistered. Without this sleep time, the
unsolicited message reporting being unregistered may arrive *after* having
checked registration status in the Simple connect sequence, and therefore we
end up failing the connection request.
Renamed `MMCommonSimpleProperties' to `MMSimpleStatus', and removed the
`MMSimpleStatusProperties' provided in libmm-glib. We'll just use the original
one from libmm-common always.
Renamed `MMCommonConnectProperties' to `MMSimpleConnectProperties', and removed
the `MMModemSimpleConnectProperties' provided in libmm-glib. We'll just use the
original one from libmm-common always.
Renamed `MMCommonBearerProperties' to `MMBearerProperties', and removed the
`MMBearerProperties' provided in libmm-glib. We'll just use the original one
from libmm-common always.
ModemManager will load:
1) The list of supported bands. Note that this doesn't mean that any possible
combination of bands is supported, as modems may support only specific
combinations, but at least gives a rough idea of what the modem is capable
of handling.
2) The list of CURRENT bands. There is no such "Allowed" bands, as we do with
modes, modems will have a specific set of bands being currently used, which
will be reported in the `Bands' property.
If the modem allows modifying the list of bands to use, this can be done with
the `SetBands()' method. If the modem doesn't support using a specific
combination of bands, this method will report an error.
For mixed 3GPP+CDMA modems, we check registrations in both 3GPP and CDMA
networks, and we stop checks when we find ourselves registered in either one
or the other.
Aleksander Morgado
Dan Williams