| Age | Commit message (Collapse) | Author |
|---|
|
We want to ensure that all errors reported via DBus operations are
normalized to MM-specific errors.
We don't want to return QMI or MBIM specific errors, as those are
protocol specific and we don't want DBus clients to need to rely on
knowing which is the protocol in use by the device.
|
|
As we do in the similar modem state wait operations in the modem
interface, the caller of the wait operation may ignore the state
result as it's really not required in this case. Only looking at
whether an error is set or not is enough.
This by itself fixes a crash where
mm_iface_modem_3gpp_wait_for_packet_service_state_finish() may have
returned UNKNOWN without error set.
0x000079616c2564ed (libglib-2.0.so.0 - gtestutils.c: 3256) g_assertion_message
0x000079616c25654b (libglib-2.0.so.0 - gtestutils.c: 3282) g_assertion_message_expr
0x000057ba46231150 (ModemManager - mm-iface-modem-simple.c: 344) packet_service_attach_in_3gpp_network_step
0x000079616c0efb02 (libgio-2.0.so.0 - gtask.c: 1232) g_task_return_now
0x000079616c0eeb54 (libgio-2.0.so.0 - gtask.c: 1301) g_task_return
0x000057ba4620e5bd (ModemManager - mm-iface-modem-3gpp.c: 189) wait_for_packet_service_state_context_complete
0x000057ba4620b441 (ModemManager - mm-iface-modem-3gpp.c: 261) packet_service_state_changed
|
|
registration sequence
|
|
|
|
|
|
When a request to disable the modem arrives while the packet service
state wait is ongoing we were not correctly cancelling the operation.
The main reason for this is that this operation does not change the
modem state, and so the "wait for final state" logic in the disabling
sequence was not being considered.
We solve this by plugging in the Simple.Connect() operation
cancellable in the wait for packet service state operation. The
connection attempt will be cancelled during the disabling sequence as
well, and when that happens we will explicitly halt the packet service
state wait as well.
|
|
Instead of just waiting for the packet service to be attached, if we
waited and still didn't get it, an explicit request will be sent.
|
|
|
|
|
|
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
|
|
|
|
|
|
When we have just enabled, we want to give it some time before
starting the registration process, so that any pending registration
update that may have been scheduled during the enabling phase is
applied. We don't want to trigger a new automatic registration if
e.g. we're already registered.
|
|
The 'ENABLE + 1' step is 'WAIT_FOR_ENABLED' really, and that should be
only used when the current state is not a final one. If we're already
enabled, or registered, or connected, then jump to 'REGISTER' right
away.
|
|
We define a new 'profile-id' setting in the bearer properties that
users will use to specify which connection profile of the ones
available in the device should be connected.
When the 'profile-id' is given, the associated bearer object will be
bound to the 'profile-id', and the user is able to provide additional
settings to apply on top (e.g. if the profile storage doesn't allow
some of the settings we support, like 'apn-type', or if the setting is
completely unrelated to profiles, like 'multiplex').
After introducing the 'profile-id' as a valid setting in the bearer
properties, we also reimplement the properties object internals to
make use a 3GPP profile for the subset of common settings between both
objects.
|
|
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
|
|
|
|
|
|
This property was never initialized with a correct value, we would
always use the same value as used for MaxActiveBearers, which isn't
technically right. Just suggest to ignore this property, and flag
it as deprecated.
In addition to deprecating the API property, we will internally no
longer limit the amount of bearer objects that may be created with
different connection settings. The bearer object exposed in DBus is a
representation of the connection that may be setup, and so we can hold
as many representations as we want as long as the amount of connected
bearers doesn't exceed the maximum amount for each modem.
Leaving around the disconnected modems also serves another purpose.
Each bearer holds information about the amount of times a connection
with it has been attempted, and the amount of data transferred through
it. If we use the Simple.Connect() method to connect the modem using
different bearer settings, we won't lose the information of the past
connection attempts with different settings.
|
|
|
|
|
|
|
|
mm-iface-modem-simple.c: In function ‘connection_step’:
mm-iface-modem-simple.c:539:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
539 | ctx->step++;
| ~~~~~~~~~^~
...
|
|
mm-iface-modem-simple.c: In function ‘connection_step’:
mm-iface-modem-simple.c:536:5: error: switch missing default case [-Werror=switch-default]
536 | switch (ctx->step) {
| ^~~~~~
|
|
The request for forced registration is an implementation detail of
mm_iface_modem_3gpp_register_in_network(), not part of any state to
keep in the private info.
|
|
If the Simple.Connect() operation fails before the bearer connection
process starts (e.g. during the previous SIM-PIN checks or explicit
registration attempt), the ongoing connect cancellable is not being
properly cleared, and this would prevent additional new connection
attempts unless an explicit Simple.Disconnect() is called.
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
Fix this, by making sure the ongoing connect cancellable is always
cleared when completing the DBus method invocation that created it.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/169
|
|
[11642]: <debug> [1573665255.321490] Couldn't reload current power state: QMI operation failed: Transaction timed out
[11642]: <debug> [1573665255.321697] No need to change power state: already in 'on' power state
[11642]: <debug> [1573665255.330864] Modem (Quectel) '/sys/devices/platform/ehci-platform/usb1/1-1' completely disposed
**
ERROR:mm-iface-modem-simple.c:44:private_free: assertion failed: (!priv->ongoing_connect)
If the modem goes away in the middle of a connection attempt, there's
no explicit connection cancellation performed, we just cleanup the
modem object. In this case, the ongoing attempt cancellable will still
exist, so just clean it up as well.
|
|
We only allow one single Simple.Connect() attempt at a time. If more
than one arrives, the second and next ones will be forbidden.
The ongoing connection attempt can now always be cancelled via
Simple.Disconnect(), not only *after* the bearer object connection has
started. i.e. if Simple.Disconnect() is called e.g. while waiting to
be registered, we would also be cancelled properly.
|
|
|
|
The Simple.Disconnect() method handler was totally broken when a
specific bearer path was given, because the user-provided bearer path
was never being stored in the DisconnectionContext struct...
This is an extremely bad error, but it also gives us an indication
that no one is really using this method to disconnect one single
bearer, mainly because we also have the Bearer.Disconnect() method,
which makes more sense. mmcli didn't even allow passing a bearer path
to --simple-disconnect.
|
|
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/99
|
|
|
|
|
|
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
|
|
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
|
We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
|
|
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
|
|
... and 'SetBands()' to 'SetCurrentBands()'.
We'll keep the 'Current' keyword in those properties which also have
'Supported' values.
|
|
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
|
|
|
|
The logic to handle the lock information (current lock and unlock retry count)
wasn't handling all possible cases properly, e.g.:
* When PIN is incorrectly entered too many times, a SIM-PUK error may happen.
In this case we need to directly assume SIM-PUK is the current lock (some
modems, like Option HSO ones, would incorrectly reply SIM-PIN if CPIN? asked
just after the SIM-PUK error).
* After every operation acting in SIM locks, we need to update the current
unlock retry count.
This change tries to cover those cases, by:
* The logic to check current lock is extended to also load the unlock retry
count when needed.
* Whenever a SIM-PUK error happens in the SIM operations, we directly assume
that SIM-PUK is required, without re-asking CPIN?.
* The overall logic of lock checking is now handled by a state machine, which
is much easier to understand.
|
|
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.
|
|
|
|
If the band isn't actually given, don't try to enable it.
|
|
|
|
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.
|
