Since commit 63dd4ad2 it is possible that the GPS interface is in use at
the time of modem reinitialization so it should not be stopped in such
case.
Otherwise "mmcli --location-status" will still say that GPS is enabled but
no GPS traces are going to be coming.
This avoids the "port in device added after device probing has already
finished" warning, and also the creation of modem objects for single
port devices.
Currently, the operator description update is only triggered once in the
entire update process. But this can lead to a operator description
updated at the wrong time. And is therefore possibly wrong.
The deprecated API call 'qmi_client_nas_get_serving_system' always triggers
an update of the operator description in there subfunction of the callback.
This is missing for the API call 'qmi_client_nas_get_system_info'. To solve
this, an update is now also triggered in the subfunction callback if there
is new system info available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
When using a modem with the qmi plugin, the operator description is only
set once for the current modem object. This is the operator description
of the mobile network to which the modem has first established a connection.
The operator description will no longer be updated even though on a
reconnection with a different mobile network.
Normally this is not a problem, as the SIM card usually dials into the
home network and stays there. But if an IoT SIM card is used, then this
is a problem because the operator description is no longer updated.
To fix this, the 'current_operator_description' is always loaded on
'modem_3gpp_load_operator_name' regardless of whether an operator
description has ever been set.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
The modem location interface loads modem location capabilities only during
the very first initialization of this interface.
On each later reinitialization it skips loading these capabilities from
modem, however it still goes through the whole interface initialization
state machine.
This state machine uses its own "ctx->capabilities" field for temporary
capabilities storage, which is set to MM_MODEM_LOCATION_SOURCE_NONE at the
start of the initialization process.
However, if we aren't actually loading modem location capabilities because
we're only reinitializing the interface we still need to set this
"ctx->capabilities" field to the existing (previously loaded) modem
location capabilities.
Otherwise the next interface initialization step (validation) will
permanently disable the whole location interface.
The generic MBIM modem implementation does not have location
capabilities support, so the relevant function pointers in the
interface are NULL.
Fixes: 306566ad7e
We should not blindly assume that peek_port_primary() always returns a
valid port, because the device may have been ejected while the AT
sequence is running.
Instead, keep a valid port object reference in the operation context,
and use it in all the AT command requests. The requests will fail if
the device has been ejected, but the port object reference will be
valid and the daemon won't crash.
There exists code paths in which the IPv4 and IPv6 WDS extended IP
config indication signal handlers are not disconnected. This results in
a ModemManager crash when an indication signal handler callback is
invoked for a bearer that no longer exists. ModemManager crashes because
the callback function (extended_ip_config_indication_received) tries to
write a log and use the ID of a non-existent bearer.
This patch ensures the extended IP config signal handlers are
disconnected when the bearer connection is reset.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/794
The generic MMBroadbandModemFibocom object uses the shared Fibocom
settings to load the update settings. This logic does not use the
Private info right now, but there is no reason why it wouldn't do it
in the future. Also, for consistency, it makes sense to ensure the
shared interface setup is the same in all implementations, we should
not have only some allowing to initialize the Private info.
Compilation errors due to generated files is observed when
compiling in multi threaded environment, as the generated files
getting generated after they have been referred.
Fix: Added dependency in meson so that it will ensure that the
header is generated.
Ref fail log:
../mobile-broadband/ModemManager/src/plugins/huawei/mm-modem-helpers-huawei.c:29:10:
fatal error: mm-huawei-enums-types.h: No such file or directory
29 | #include "mm-huawei-enums-types.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Signed-off-by: Kamesh Relangi <quic_krelangi@quicinc.com>
There is no guarantee from the kernel that the ports of a given device
will all be notified via uevents on a timely manner. We assume it, but
we cannot be completely sure.
There are two main scenarios that we have been seen when the ports of a
device are not notified close enough to each other:
* A modem object is created, but not with the desired control protocol.
E.g. a QMI or MBIM modem would end up controlled via AT commands if
the cdc-wdm port was added too late.
* A modem object is not created at all, and the device object was
removed completely. E.g. when the net port addition in a QMI or MBIM
modem happens too late.
In order to avoid those cases, we will now fully reprobe all the ports
of the device from scratch whenever a new valid port addition happens
after the initial probing of the device has already been completed. If a
modem object is available at that time, we will remove it right away.
Rework the AT string quote operation to build the output with the
GString helper, instead of manually calculating how many bytes we'll
need in the output. It just makes it clearer.
We cannot assume that the ports may be peeked after the AT sequence
has finished, because they may have been already removed. We can store
a full port reference instead, to ensure the validity of the objects
at that time.
==19351== Process terminating with default action of signal 5 (SIGTRAP)
==19351== at 0x4A1DB24: g_logv (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A1DDB2: g_log (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x28B54E: mm_port_get_device (mm-port.c:62)
==19351== by 0x1B1247: modem_messaging_enable_unsolicited_events_secondary_ready (mm-broadband-modem.c:7373)
==19351== by 0x4BA37D8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==19351== by 0x4BA381C: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==19351== by 0x4A157EE: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A68D27: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A14E52: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x176B91: main (main.c:236)
Requiring an explicit set of drivers should only be done when we have
different plugins supporting different types of devices of the same
manufacturer based on the drivers in use (e.g. as in the Sierra case).
When the plugin includes a list of required drivers, the plugin filter
will only assume the plugin can be used if at least one of the
available ports is exposed with one of the drivers in the list.
Because of this, if we start probing some ports before all the
expected ports are reported, we may end up not selecting a given
plugin just because the driver match should have been done in a
not-yet-notified port.
E.g. on system boot:
* ttyACM0 is notified.
* min probing time elapses so ttyACM0 probing starts
* Fibocom plugin is not selected for ttyACM0 as no matched
driver ("cdc_acm") is given in the the list of drivers of the
plugin.
* cdc-wdm0 and wwan0 drivers are notified.
* MM creates generic MBIM modem with the Fibocom plugin, but without
XMM features support, because the ttyACM0 port probing was not done
by the Fibocom plugin.
And if we reset the modem after that:
* ttyACM0 is notified.
* cdc-wdm0 and wwan0 drivers are notified.
* min probing time elapses so probing starts for all ports
* Fibocom plugin is selected for all port probings as "cdc_mbim" is
listed in the list of drivers of the plugin.
* MM creates XMM-capable MBIM modem with the Fibocom plugin.
mm_parse_uint_list() sorts available SIMs and possibly changes the order of the active / non-active SIM.
A custom parser is added, which keeps the order of all SIMs.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
Maciej S. Szmigiero
Aleksander Morgado
Aleksander Morgado
Florian Eckert
Dan Williams
Steve Leung
Oliver Kästner
Yegor Yefremov
Samuel Valery
bolan wang
Z-张旭
Kamesh Relangi
Lukas Voegl