Age | Commit message (Collapse) | Author |
|
It won't ever change over the lifetime of the BaseSMS.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Expose a new list of 'IgnoredPorts' via D-Bus and therefore remove the use of `MM_MODEM_PORT_TYPE_IGNORED`
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
If the old IMSI was unavailable because the SIM was locked, but now
is available because the SIM was unlocked, don't treat the SIM
properties change as a hotswap that may trigger dropping and re-probing
the modem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
All in debug messages or code comments so not user / client visible.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
|
|
When setting an operator, AT+COPS overwrites the currently set allowed mode. Equally, the other way around, when setting the current mode, the configured operator is overwritten.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
If we are going to inhibit the modem or fully reprobe it after a SIM
switch event, we should forbid further operations done with the modem
object.
This logic can be tested by queing different operations one after the
other, and then adding a last device inhibition ("override" operation)
that should trigger the early abort of all non-running operations,
e.g.:
mmcli -m a -e &
sleep 0.2
mmcli -m a --3gpp-set-initial-eps-bearer-settings="apn=internet,ip-type=ipv4v6,force=true" &
sleep 0.2
mmcli -m a -d &
sleep 0.2
mmcli -m a -e &
sleep 0.2
mmcli -m a --set-power-state-low &
sleep 0.2
mmcli -m a -e &
sleep 0.2
mmcli -m a --inhibit
This previous sequence produces MM logs as follows:
<dbg> [1726567756.430308] [modem0] [operation 22] default - enable: scheduled
<dbg> [1726567756.430806] [modem0] [operation 22] default - enable: lock acquired
<dbg> [1726567756.623746] [modem0] [operation 23] default - set-initial-eps-bearer-settings: scheduled
<dbg> [1726567756.751743] [modem0] [operation 22] default - enable: lock released
<dbg> [1726567756.752027] [modem0] [operation 23] default - set-initial-eps-bearer-settings: lock acquired
<dbg> [1726567756.823739] [modem0] [operation 24] default - disable: scheduled
<dbg> [1726567757.049581] [modem0] [operation 25] default - enable: scheduled
<dbg> [1726567757.250165] [modem0] [operation 26] default - set-power-state: scheduled
<dbg> [1726567757.450518] [modem0] [operation 27] default - enable: scheduled
<dbg> [1726567757.676362] [modem0] [operation 28] override - disabling: override requested - no new operations will be allowed
<dbg> [1726567757.678792] [modem0] [operation 24] default - disable: aborted early
<dbg> [1726567757.679866] [modem0] [operation 25] default - enable: aborted early
<dbg> [1726567757.680157] [modem0] [operation 26] default - set-power-state: aborted early
<dbg> [1726567757.680496] [modem0] [operation 27] default - enable: aborted early
<dbg> [1726567759.695780] [modem0] [operation 23] default - set-initial-eps-bearer-settings: lock released
<dbg> [1726567759.695935] [modem0] [operation 28] override - disabling: lock acquired
<dbg> [1726567759.872196] [modem0] [operation 28] override - disabling: lock released
|
|
This logic can be tested by queing different operations one after the
other, e.g.:
mmcli -m a -e &
sleep 0.2
mmcli -m a --3gpp-set-initial-eps-bearer-settings="apn=internet,ip-type=ipv4v6,force=true" &
sleep 0.2
mmcli -m a -d &
sleep 0.2
mmcli -m a -e &
sleep 0.2
mmcli -m a --set-power-state-low &
sleep 0.2
mmcli -m a -e &
This previous sequence produces MM logs as follows:
<dbg> [1726567176.214906] [modem0] [operation 15] default - enable: scheduled
<dbg> [1726567176.215108] [modem0] [operation 15] default - enable: lock acquired
<dbg> [1726567176.436234] [modem0] [operation 16] default - set-initial-eps-bearer-settings: scheduled
<dbg> [1726567176.554153] [modem0] [operation 15] default - enable: lock released
<dbg> [1726567176.554492] [modem0] [operation 16] default - set-initial-eps-bearer-settings: lock acquired
<dbg> [1726567176.619021] [modem0] [operation 17] default - disable: scheduled
<dbg> [1726567176.840024] [modem0] [operation 18] default - enable: scheduled
<dbg> [1726567177.037155] [modem0] [operation 19] default - set-power-state: scheduled
<dbg> [1726567177.240225] [modem0] [operation 20] default - enable: scheduled
<dbg> [1726567179.496397] [modem0] [operation 16] default - set-initial-eps-bearer-settings: lock released
<dbg> [1726567179.496576] [modem0] [operation 17] default - disable: lock acquired
<dbg> [1726567179.672141] [modem0] [operation 17] default - disable: lock released
<dbg> [1726567179.672658] [modem0] [operation 18] default - enable: lock acquired
<dbg> [1726567179.938481] [modem0] [operation 18] default - enable: lock released
<dbg> [1726567179.940470] [modem0] [operation 19] default - set-power-state: lock acquired
<dbg> [1726567182.147894] [modem0] [operation 19] default - set-power-state: lock released
<dbg> [1726567182.148041] [modem0] [operation 20] default - enable: lock acquired
<dbg> [1726567184.494469] [modem0] [operation 20] default - enable: lock released
iface-modem-3gpp: operation lock in all operations that change state
|
|
Each of these now holds an exclusive lock, so all these operations are
synchronized.
This logic can be tested by queing different enable/disable operations
one after the other, e.g.:
mmcli -m a -d & --> Disable 1
sleep 0.2
mmcli -m a -e & --> Enable 1
sleep 0.2
mmcli -m a -e & --> Enable 2
sleep 0.2
mmcli -m a -d & --> Disable 2
sleep 0.2
mmcli -m a -e & --> Enable 3
sleep 0.2
mmcli -m a -d & --> Disable 3
This previous sequence produces MM logs as follows:
<dbg> [1726566352.936025] [modem0] [operation 9] default - disable: scheduled --> Disable 1 requested
<dbg> [1726566352.936399] [modem0] [operation 9] default - disable: lock acquired --> Disable 1 started
<dbg> [1726566353.136445] [modem0] [operation 10] default - enable: scheduled --> Enable 1 requested
<dbg> [1726566353.202980] [modem0] [operation 9] default - disable: lock released --> Disable 1 finished
<dbg> [1726566353.203526] [modem0] [operation 10] default - enable: lock acquired --> Enable 1 started
<dbg> [1726566353.320057] [modem0] [operation 11] default - enable: scheduled --> Enable 2 requested
<dbg> [1726566353.440931] [modem0] [operation 10] default - enable: lock released --> Enable 1 finished
<dbg> [1726566353.443238] [modem0] [operation 11] default - enable: lock acquired --> Enable 2 started
<dbg> [1726566353.452984] [modem0] [operation 11] default - enable: lock released --> Enable 2 finished
<dbg> [1726566353.517512] [modem0] [operation 12] default - disable: scheduled --> Disable 2 requested
<dbg> [1726566353.517699] [modem0] [operation 12] default - disable: lock acquired --> Disable 2 started
<dbg> [1726566353.688695] [modem0] [operation 12] default - disable: lock released --> Disable 2 finished
<dbg> [1726566353.718237] [modem0] [operation 13] default - enable: scheduled --> Enable 3 requested
<dbg> [1726566353.718417] [modem0] [operation 13] default - enable: lock acquired --> Enable 3 started
<dbg> [1726566353.937122] [modem0] [operation 14] default - disable: scheduled --> Disable 3 requested
<dbg> [1726566353.970791] [modem0] [operation 13] default - enable: lock released --> Enable 3 finished
<dbg> [1726566353.970964] [modem0] [operation 14] default - disable: lock acquired --> Disable 3 started
<dbg> [1726566354.170938] [modem0] [operation 14] default - disable: lock released --> Disable 3 finished
|
|
MMBroadbandModemQmi only disables signal polling once it successfully
sets the indication up. To do that, it sets the properties on
MMIfaceModem. This, however, doesn't actually disable polling, as the
property values are only checked once in get_private when Private
structure hasn't been created yet. Once that happens, only the cached
values are ever checked, and there's nothing that would update them.
Since there's only one place where these properties are checked, get
rid of cached bools in Private structure and instead read the property
values directly in periodic_signal_check_step, letting QMI modems
actually disable polling at runtime.
|
|
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
Let the caller of mm_iface_modem_set_power_state() know which was the
power state in the device before the actual update happened.
This is useful in cases where we want to temporarily switch to a given
power state (e.g. low) before returning to the original power state.
|
|
|
|
|
|
Modems may have certain features only available in new firmware
versions. We should try to load the firmware revision as soon as
possible, even before creating the bearer list, as that informs
already about multiplexing support in the device.
|
|
If the user requested to set the modem in low power mode while
enabled, the user is also expecting the device to be implicitly
disabled.
If for any reason setting the modem to low power mode fails (e.g. it
could be not supported by the device), we should still try to run the
modem disabling sequence, as that is the expectation.
|
|
We now enable low-power mode request if we are enabled or even
connected. In this case, an explicit modem disable operation is run,
so that we don't end up with an enabled modem in low-power mode.
This new "low-power+disable" single operation makes the two
"disable+low-power" operation combo that was run until now much much
quicker, because the modem unregisters from the network and
disconnects PDNs in the same network interaction.
|
|
This change is an attempt to behave a bit better with modems when
multiple consecutive enable/full-power/disable/low-power operations
are scheduled in a modem.
MM will automatically throttle these requests so that the power state
updates are spaced in time, with at least 2 full seconds between
them.
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/802
|
|
The process doing the unlock required checks may need a lot of retries
e.g. to decide whether a SIM card is available or not. If we do a
quick SIM eject, so the unlock required check starts looping, and then
insert the SIM again, we expect the loop to be cancelled right away,
so that the new modem object can be reprobed without any interference
from the old modem object.
We now take the modem-wide cancellable and bind it to the GTask in
mm_iface_modem_update_lock_info(), and we pass it down to every
sub-step of the async logic in the operation. We also plug the
cancellable to the delayed retries in the interface logic, to allow
aborting the checks right away
|
|
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.
|
|
This improves SIM hot swap check process, and it can help avoid unnecessary
modem reprobe during suspend-resume without SIM inserted.
The changes in this CL implemented the new logic ONLY for MBIM, and the
new logic has not been implemented for QMI and AT yet. Thus, we keep the
legacy `mm_iface_modem_check_for_sim_swap()' till the new logic for QMI
and AT has been implemented.
|
|
|
|
iface-modem does not include config.h so it doesnt actually have the meson
generated build defines to check against.
I found this while trying to use AT commands over D-Bus by enabling
at_command_via_dbus, confirming that Meson sees it, defines it in config.h
but then I still got the:
"Cannot send AT command to modem: operation only allowed in debug mode".
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
|
|
|
|
Since 503e886c02 the events on inactive SIMs don't trigger a full
modem reprobe, and the slot index check is fully unused.
|
|
Explicitly return TRUE to indicate success because otherwise the
caller will expect a valid GError set.
|
|
On MBIM modems, when the SIM is ejected and re-inserted in a quick manner,
the state machine logic encounters a race condition and eventually, the
modem response for subscriber status is ignored. This change accounts
for that state transition without erroring out.
Fixes #672.
|
|
In some cases modem is taking 7 tries to detect an initialized SIM.
|
|
Whenever an explicit signal refresh was requested we would flag the
check as ongoing but never reset the flag, so it would never attempt
to reload it again.
Fixes 0080ed612d0a412c5794059a93ed30ca07103b79
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/702
|
|
Instead of warning about various unimportant things failing that don't
affect functionality, just print the logs in debug level and go on.
E.g. this warning can be completely skipped:
<wrn> [modem0] couldn't load list of own numbers: Couldn't get MSISDN: QMI protocol error (16): 'NotProvisioned'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Avoid removing 3GPP capabilities if sim is absent.
Transition to 'Failed' state for 3GPP capable devices if sim is absent.
|