Just ignoring the received indications is not enough, because they
could arrive after the operation response has been processed.
We now explicitly disable the indications by reconfiguring the modem
before and after every profile update operation triggered by our own
logic.
When Telit FN990 is integrated through PCIe, but also USB lines are
available, ModemManager will consider the port on the USB composition
as a different modem:
oem@sw-test:~$ mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [telit] FN990A40
/org/freedesktop/ModemManager1/Modem/0 [Telit] FN990A40
oem@sw-test:~$ mmcli -m 0
<snip>
| equipment id: 359172390022295
--------------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-5
| drivers: option
| plugin: telit
| primary port: ttyUSB0
| ports: ttyUSB0 (at)
oem@sw-test:~$ mmcli -m 1
<snip>
| equipment id: 359172390022295
-----------------------------------
System | device: /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0
| drivers: mhi-pci-generic
| plugin: telit
| primary port: wwan0mbim0
| ports: wwan0 (net), wwan0at0 (at), wwan0at1 (at),
| wwan0mbim0 (mbim), wwan0nmea0 (ignored), wwan0qcdm0 (ignored)
Ignore composition 0x1075, since it should not be used by ModemManager
and can only show when PCIe is used.
On MBIM modems that do not support mbimex v2, extra steps are required
to retrieve 3G/4G signal quality markers from the modem when using
thresholds to trigger signal quality indications.
[1/2] Compiling C object src/ModemManager.p/mm-base-manager.c.o
../src/mm-base-manager.c: In function ‘remove_device_inhibition’:
../src/mm-base-manager.c:1127:20: warning: declaration of ‘l’ shadows a previous local [-Wshadow]
1127 | GList *l;
| ^
../src/mm-base-manager.c:1116:16: note: shadowed declaration is here
1116 | GList *l;
| ^
If the device is not fully removed from the system during inhibition
and port additions happen, we reach a state where the MMDevice object
is still tracked by ModemManager and we also have new port additions
tracked that will require explicit port probings before a new modem
object can be created.
Solve this mixup by faking the removal of all existing device ports,
which will end up completely removing hte MMDevice, so that new port
additions reported afterwards also involve the full device probing
process triggered by the plugin manager.
The issue could be reproduced easily on a MBIM device that also
exposed TTYs, as follows:
* mmcli -m a --inhibit, leave it running
* rmmod cdc_mbim && sleep 5 && modprobe cdc_mbim (so that the
cdc-wdm and net ports go away from the system but NOT the TTYs.)
* Cltr+C to stop the inhibit in the mmcli call.
ModemManager would assert as follows:
0x000079918bcf2a3f (libc.so.6 + 0x00087a3f) pthread_key_delete
0x000079918bca7c6c (libc.so.6 + 0x0003cc6c) gsignal
0x000079918bc93462 (libc.so.6 + 0x00028462) abort
0x000079918bf26f03 (libglib-2.0.so.0 - gtestutils.c: 3253) g_assertion_message
0x000079918bf26f66 (libglib-2.0.so.0 - gtestutils.c: 3279) g_assertion_message_expr
0x0000594ff1093d0c (ModemManager - mm-base-manager.c: 1110) remove_device_inhibition
0x0000594ff1093968 (ModemManager - mm-base-manager.c: 1247) inhibit_device_auth_ready
0x000079918c0536a8 (libgio-2.0.so.0 - gtask.c: 1230) g_task_return_now
0x000079918c0536db (libgio-2.0.so.0 - gtask.c: 1244) complete_in_idle_cb
0x000079918bf053fc (libglib-2.0.so.0 - gmain.c: 3417) g_main_context_dispatch
0x000079918bf05704 (libglib-2.0.so.0 - gmain.c: 4211) g_main_context_iterate
0x000079918bf05978 (libglib-2.0.so.0 - gmain.c: 4411) g_main_loop_run
0x0000594ff108de66 (ModemManager - main.c: 217) main
0x000079918bc936c5 (libc.so.6 + 0x000286c5) __libc_init_first
0x000079918bc93781 (libc.so.6 + 0x00028781) __libc_start_main
0x0000594ff108db80 (ModemManager + 0x00061b80) _start
The Tethering context type UUID was defined by Microsoft in its
extensions as `5e4e0601-48dc-4e2b-acb8-08b4016bbaac` (along with
others like Admin, Xcap, App and EmergencyCalling), see
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/mb-provisioned-context-operations.
These UUIDs are expected to be usable only if the modem supports
`MBIM_CID_MS_PROVISIONED_CONTEXT_V2` (CID=1) in the Basic Connect
Extensions service (3d01dcc5-fef5-4d05-0d3abef7058e9aaf).
If the modem doesn't support these, we should try to fallback to a
more generic APN type automatically, e.g. "Internet", which was
defined in MBIM 1.0 and should always be supported.
There should be no problem in a modem to have 2 separate PDN
connections with the same context type.
If we remove the current element being iterated in the GList, we can
no longer call g_list_next() on it. Ensure we keep a valid pointer to
the next element in the list before removing the current one.
It was not possible to read IMEI of modem when SIM was not inserted or
initialization failed due to modem facility locks. To load IMEI, the
3gpp interface need to be initialized before going to FALLBACK_LIMITED.
Some firmware versions return an empty string for the revision when
using the device caps MBIM request, so use AT commands as a fallback
in case this happens.
This commit modifies the QMI DMS Operating Mode indication registration logic.
During the power sequence chance, if a QMI_PROTOCOL_ERROR_MISSING_ARGUMENT error
was returned in "DMS Set Event Report" operation for Operating Mode Reporting failed,
the whole sequence was aborted, leading the modem to be disabled.
<debug> [modem0] Power indication registration request is sent
...
<debug> [modem0] couldn't update power state: Couldn't register for power indications: QMI protocol error (17): 'MissingArgument'
<warn> [modem0] couldn't enable interface: 'Couldn't register for power indications: QMI protocol error (17): 'MissingArgument''
<debug> [modem0] running implicit disable after failed enable...
This commit modifies the logic to properly detect the failure and
continue the sequence without the indications.
Fixes#683
Signed-off-by: Louis-Alexis Eyraud <louis-alexis.eyraud@unabiz.com>
When using qmi uim service from mbim broadband modem, a fallback from using
qmi uim service to normal mbim operations is done every time a call to
qmi_set_primary_sim_slot fails. But this may fall for various reasons,
and a fallback only makes sense when the device does not support that call
Patch reworked by Aleksander Morgado <aleksandermj@chromium.org>
ModemManager[562783]: <err> [1673538458.350130] mm_utils_bin2hexstr: assertion 'bin != NULL' failed
ModemManager[562783]: <dbg> [1673538458.350167] [modem0/bearer0] container ID: 0
ModemManager[562783]: <dbg> [1673538458.350201] [modem0/bearer0] app specific info: (null)
Treat it better by only trying to build the app specific info string
if there are contents in the array.
The device may emit a "WDS Profile Changed" indication triggered from
our own "WDS Modify Profile", "WDS Create Profile" or "WDS Delete
Profile" operations, so ensure those are fully ignored so that we
don't emit the "Updated" signal in the ProfileManager interface.
The logic keeps track of the amount of concurrent operations so that
the signal is ignored for as long as there is at least one operation
running.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/687
Instead of creating libmm-plugin* and libmm-shared* libraries that are
dlopen()-ed on runtime, allow incorporating all plugins into the
daemon binary itself.
This makes the startup of the daemon much faster and also avoids
issues with builds that require linker namespace isolation.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/674
<wrn> [plugin-manager] could not load shared '/usr/lib/ModemManager/libmm-shared-xmm.so': Missing major version info
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x000055555562b79d in load_external_shared (path=<optimized out>, self=0x5555557b5880) at ../src/mm-plugin-manager.c:1885
1885 if (module && !(*shared_name))
(gdb) p module
$1 = (GModule *) 0x5555557b9670
(gdb) p shared_name
$2 = (const gchar **) 0x0
We are going to allow including the plugin sources built within the
ModemManager daemon binary; moving the sources within the daemon
sources directory makes it easier.
The 'link_ports' and 'ports' tables are created during object init(),
but they are fully removed and cleared during dispose(). Given that
the MMDevice executes an explicit g_object_run_dispose(), there may be
cases where a long-running operation that isn't cancelled ends up
being completed by the time the object disposal has already run at
least once.
That would end up crashing the process if we attempt to e.g. iterate
over one of the ports hash tables:
0x00007c3594eb3b93 (libglib-2.0.so.0 - ghash.c: 1180) g_hash_table_iter_next
0x00005b60d86f2563 (ModemManager - mm-base-modem.c: 1133) mm_base_modem_get_port_infos
0x00005b60d870228e (ModemManager - mm-iface-modem.c: 4013) fcc_unlock
0x00007c35950126a8 (libgio-2.0.so.0 - gtask.c: 1230) g_task_return_now
0x00007c35950116fa (libgio-2.0.so.0 - gtask.c: 1300) g_task_return
0x00007c3595011d12 (libgio-2.0.so.0 - gtask.c: 1930) g_task_return_new_error
0x00005b60d87518f2 (ModemManager - mm-broadband-modem-mbim.c: 1970) radio_state_set_up_ready
0x00007c35950126a8 (libgio-2.0.so.0 - gtask.c: 1230) g_task_return_now
0x00007c35950116fa (libgio-2.0.so.0 - gtask.c: 1300) g_task_return
0x00007c35950c486c (libmbim-glib.so.4 - mbim-device.c: 253) transaction_task_complete_and_free
0x00007c35950c714b (libmbim-glib.so.4 - mbim-device.c: 335) transaction_timed_out
0x00007c3594ec1232 (libglib-2.0.so.0 - gmain.c: 4971) g_timeout_dispatch
0x00007c3594ec43fc (libglib-2.0.so.0 - gmain.c: 3417) g_main_context_dispatch
0x00007c3594ec4704 (libglib-2.0.so.0 - gmain.c: 4211) g_main_context_iterate
0x00007c3594ec4978 (libglib-2.0.so.0 - gmain.c: 4411) g_main_loop_run
0x00005b60d86d7c56 (ModemManager - main.c: 217) main
0x00007c3594c526c5 (libc.so.6 + 0x000286c5) __libc_init_first
0x00007c3594c52781 (libc.so.6 + 0x00028781) __libc_start_main
0x00005b60d86d7970 (ModemManager + 0x00061970) _start
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/677
Change-Id: I6695c284f86a196e60de7f714bc1671332d08848
Instead of having the modem object listen notifications in the
MbimDevice, the MMPortMbim will act as an intermediate emitter for the
same.
The primary benefit is that the lifecycle of the port object is
tightly coupled to the life of the modem object, so there is no chance
that the port object outlives the modem object.
And the port object will ensure its own device notification handler is
correctly cleared up on its dispose, so there should be no chance of
firing up a signal in the device for a listener that is already
freed.
Letting the MMBroadbandModemMbim listen for the notifications of the
MbimDevice was not a good idea, especially since no explicit reference
to the device object was hold in the modem object. This leads to race
conditions in which the MbimDevice outlives the MMBroadbandModemMbim and
the MMPortMbim, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortMbim will now emit its own 'removed' signals when the
underlying MbimDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortMbim disposal.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/518
Letting the MMBroadbandModemQmi listen for the notifications of the
QmiDevice was not a good idea, especially since no explicit reference
to the device object was hold in the modem object. This leads to race
conditions in which the QmiDevice outlives the MMBroadbandModemQmi and
the MMPortQmi, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortQmi will now emit its own 'removed' signals when the
underlying QmiDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortQmi disposal.
This signal indicates that the port is no longer accessible. Unlike a
udev port removal event, this indication may happen even if the port
is still exposed by the system.
It is designed to detect protocol proxy crashes, and so when such
event is detected by the modem, a full reprobe of the device will be
done to start from scratch the protocol management operations.
If the modem is already registered when ModemManager probes the modem,
it will ignore the registration state since the modem is not enabled
yet. Always querying the registration state before starting the
registration procedure makes sure to catch such cases and not perform
unnecessary registration steps.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
