| Age | Commit message (Collapse) | Author |
|---|
|
This patch add fibocom FM135 to 77-mm-fibocom-port-types.rules file. The vid and pid of the module is "2cb7 0115".
|
|
|
|
|
|
|
|
|
|
Make sure all Fibocom modem implementations use the shared port setup
logic that adds the SIM READY URC ignore rule.
|
|
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>
|
|
The logic to build the generic device ids may run by the time we have
already removed the ports in the modem. If so, just cleanly error out
and avoid the assertion.
0x00007df14bb03a3f (libc.so.6 - pthread_kill.c: 44) __pthread_kill_implementation
0x00007df14bab8c6c (libc.so.6 - raise.c: 26) raise
0x00007df14baa4462 (libc.so.6 - abort.c: 79) abort
0x00007df14c2c8686 (libglib-2.0.so.0 - gtestutils.c: 3450) g_assertion_message
0x00007df14c2c86fa (libglib-2.0.so.0 - gtestutils.c: 3476) g_assertion_message_expr
0x000059ff23c90c90 (ModemManager - mm-iface-modem-firmware.c: 353) mm_iface_firmware_build_generic_device_ids
0x000059ff23ceef7d (ModemManager - mm-shared-fibocom.c: 495) fibocom_at_port_get_firmware_version_ready
0x00007df14c158e57 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now
0x00007df14c158e8a (libgio-2.0.so.0 - gtask.c: 1323) complete_in_idle_cb
0x00007df14c2a47a4 (libglib-2.0.so.0 - gmain.c: 3460) g_main_dispatch
0x00007df14c2a47a4 (libglib-2.0.so.0 - gmain.c: 4200) g_main_context_dispatch
0x00007df14c2a4ac3 (libglib-2.0.so.0 - gmain.c: 4276) g_main_context_iterate
0x00007df14c2a4d41 (libglib-2.0.so.0 - gmain.c: 4479) g_main_loop_run
0x000059ff23c43741 (ModemManager - main.c: 221) main
0x00007df14baa46c5 (libc.so.6 - libc_start_call_main.h: 58) __libc_start_call_main
0x00007df14baa4781 (libc.so.6 - libc-start.c: 389) __libc_start_main_impl
0x000059ff23c430b0 (ModemManager + 0x000b00b0) _start
0x00007ffc53d5bd27
|
|
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>
|
|
The connect_cleanup() method takes care of cleaning up the ongoing
connect cancellables stored in the MMBearerQmi private data. Not using
it would lead to assert failures when disposing the bearer object.
0x00007ca75b4dea3f (libc.so.6 - pthread_kill.c: 44) __pthread_kill_implementation
0x00007ca75b493c6c (libc.so.6 - raise.c: 26) raise
0x00007ca75b47f462 (libc.so.6 - abort.c: 79) abort
0x00007ca75bca4688 (libglib-2.0.so.0 - gtestutils.c: 3450) g_assertion_message
0x00007ca75bca46fc (libglib-2.0.so.0 - gtestutils.c: 3476) g_assertion_message_expr
0x00005785d2f5aec4 (ModemManager - mm-bearer-qmi.c: 2974) dispose
0x00007ca75ba4cd0b (libgobject-2.0.so.0 - gobject.c: 3891) g_object_unref
0x00007ca75bc7c834 (libglib-2.0.so.0 - glist.c: 1092) g_list_foreach
0x00007ca75bc7c834 (libglib-2.0.so.0 - glist.c: 246) g_list_free_full
0x00005785d2f071a7 (ModemManager - mm-bearer-list.c: 456) dispose
0x00007ca75ba4cd0b (libgobject-2.0.so.0 - gobject.c: 3891) g_object_unref
0x00005785d2f0cf5f (ModemManager - mm-broadband-modem.c: 13420) dispose
0x00007ca75ba4cb6f (libgobject-2.0.so.0 - gobject.c: 1448) g_object_run_dispose
0x00005785d2f20ae1 (ModemManager - mm-device.c: 418) clear_modem
0x00005785d2f20d9d (ModemManager - mm-device.c: 461) modem_valid
0x00007ca75ba4820e (libgobject-2.0.so.0 - gclosure.c: 832) g_closure_invoke
0x00007ca75ba5cd00 (libgobject-2.0.so.0 - gsignal.c: 3812) signal_emit_unlocked_R
0x00007ca75ba5dd8b (libgobject-2.0.so.0 - gsignal.c: 3565) g_signal_emit_valist
0x00007ca75ba5e1d5 (libgobject-2.0.so.0 - gsignal.c: 3622) g_signal_emit
0x00007ca75ba51c6a (libgobject-2.0.so.0 - gobject.c: 1428) g_object_dispatch_properties_changed
0x00007ca75ba4d159 (libgobject-2.0.so.0 - gobject.c: 1552) g_object_notify_by_spec_internal
0x00005785d2efdf62 (ModemManager - mm-base-modem.c: 1783) base_modem_invalid_idle
0x00007ca75bc807a4 (libglib-2.0.so.0 - gmain.c: 3460) g_main_dispatch
0x00007ca75bc807a4 (libglib-2.0.so.0 - gmain.c: 4200) g_main_context_dispatch
0x00007ca75bc80ac3 (libglib-2.0.so.0 - gmain.c: 4276) g_main_context_iterate
0x00007ca75bc80d41 (libglib-2.0.so.0 - gmain.c: 4479) g_main_loop_run
0x00005785d2ef07df (ModemManager - main.c: 236) main
0x00007ca75b47f6c5 (libc.so.6 - libc_start_call_main.h: 58) __libc_start_call_main
0x00007ca75b47f781 (libc.so.6 - libc-start.c: 389) __libc_start_main_impl
0x00005785d2ef0130 (ModemManager + 0x000b1130) _start
0x00007ffd10207c37
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/822
|
|
Seen on a Huawei UMG1831 when plugged in while ModemManager is already running.
ModemManager[45407]: <dbg> [1707842298.719505] [ttyUSB2/at] device open count is 3 (open)
ModemManager[45407]: <dbg> [1707842298.719642] [ttyUSB2/at] --> 'AT+CNUM<CR>'
ModemManager[45407]: <dbg> [1707842298.728802] [ttyUSB2/at] <-- '<CR><LF>+CME ERROR: 14<CR><LF>'
ModemManager[45407]: <dbg> [1707842298.728946] [ttyUSB2/at] operation failure: 14 (SIM busy)
ModemManager[45407]: <dbg> [1707842302.097846] [ttyUSB2/at] --> 'AT+CNUM<CR>'
ModemManager[45407]: <dbg> [1707842302.109435] [ttyUSB2/at] <-- '<CR><LF>+CME ERROR: 14<CR><LF>'
ModemManager[45407]: <dbg> [1707842302.109645] [ttyUSB2/at] operation failure: 14 (SIM busy)
ModemManager[45407]: <dbg> [1707842305.098165] [ttyUSB2/at] --> 'AT+CNUM<CR>'
ModemManager[45407]: <dbg> [1707842305.107692] [ttyUSB2/at] <-- '<CR><LF>+CNUM: "","+11234567890",145<CR><LF><CR><LF><CR><LF>OK<CR><LF>'
Signed-off-by: Dan Williams <dcbw@redhat.com>
|
|
Can be used for easier command retries where the generic sequence code
handles the GTimeout source.
Signed-off-by: Dan Williams <dcbw@redhat.com>
|
|
The network error needs to be scaled down.
|
|
Required for modems that don't provide a correct 3GPP network error
value.
|
|
Old firmware versions of the FM350 had some internal IP packet filters
installed, which prevented proper IPv6 connectivity in certain cases.
This workaround ensures that the IP packet filters get removed
whenever a data connection is up. Because we don't know when exactly
the filters get installed, we do this removal periodically along with
the bearer stats query.
|
|
Old versions of the FM350 firmware were able to support multiplex with
multiple PDNs more or less consistently, except on very specific cases
like Verizon.
The newest firmware versions support multiplex on any carrier, so we
can enable back the feature depending on the firmware version number.
|
|
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.
|
|
Async SLAAC implementation in the FM350 is only available since
29.23.06, so only wait for the IP configuration indications reporting
the SLAAC result in newer versions.
|
|
When IPv6 is requested during a connection attempt, two things may
happen: either the modem itself runs SLAAC, or otherwise the host is
the one that should run SLAAC.
Until now we have assumed that the first IP configuration query that
is run upon finishing a connection attempt always gives us a "final
result", so if the modem did run SLAAC by itself, we would have
expected to see a global IPv6 reported in that first query. And if
there was no global IPv6 reported, then we would have assumed that the
host was the one tasked with running SLAAC.
There is a third option that we now consider, which is the case where
the first IP configuration query does not report a global IPv6, but
the modem is really running SLAAC, and the global IPv6 address will be
reported via a IP configuration indication as soon as SLAAC finishes.
This third option cannot be assumed by default, because it introduces
the possibility of MM waiting for the indication with the SLAAC
results and that indication never arriving in the 10s timeout used as
default. If a modem is supposed to use this third option, the feature
must be explicitly flagged by the modem plugin.
|
|
The modem object doesn't process the IP configuration updates reported
by the modem, but the MBIM bearer object may do so if waiting for
async SLAAC updates.
|
|
|
|
|
|
|
|
This modem is used for instance on the CAT B100 phone.
Signed-off-by: RICCIARDI-Adrien <adrien.ricciardi@hotmail.fr>
|
|
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.
|
|
If an IoT SIM card is used, the service name is always used as the operator
description. This is not what is expected. Therefore the priority is
changed with this commit, so that the long name is tried to be set first,
then the short name and finally the service name.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
|
With the current implementation it was not possible to find out which
operator description is now exactly used. By adding a log message, it is
now clear which operator description is now set.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
|
We currently don't use the MBIMEx profile management operations by
default because the way profiles are managed is different (i.e.
profile id as index vs context type as index).
Still, when listing profile contents, we can use the MBIMEx operation
if supported, because it gives us much more information than the
original MBIM command, including IP type and profile source.
|
|
|
|
MbimProvisionedContextElementV2
|
|
The logic implementing the operating mode update is composed of
multiple steps, some of which need to be skipped depending on previous
state.
Switch the logic to a state machine with a clear step enumeration
indicating the order of the updates.
|
|
response
When relying on the power update indications, we were completing the
operation as soon as the indication was received, regardless of
whether the request response was received or not.
Avoid doing that, and instead complete the operation only when both
indication and the response are received. This avoid misalignment in
the operation completion if a new one is scheduled just after the one
we have completed.
|
|
operation
|
|
The GTask stored in the private modem struct indicates whether a power
update operation is ongoing. We should keep this task stored always
until just before completing the GTask.
We also make sure that any additional step (e.g. disabling DMS event
report indications) is included in the power update operation, so that
they are correctly synchronized also in the modem.
This fix should solve a crash triggered by a DMS event report
indication being received while setting up the next power update
operation.
0x0000007aa67de878 (libc.so.6 + 0x0007e878) pthread_key_delete
0x0000007aa6799d28 (libc.so.6 + 0x00039d28) gsignal
0x0000007aa6786e2c (libc.so.6 + 0x00026e2c) abort
0x0000007aa6feb188 (libglib-2.0.so.0 - gtestutils.c: 3256) g_assertion_message
0x0000007aa6feb1f8 (libglib-2.0.so.0 - gtestutils.c: 3282) g_assertion_message_expr
0x0000005a58199b7c (ModemManager - mm-broadband-modem-qmi.c: 1926) dms_set_event_report_operating_mode_activate_ready
0x0000007aa6e4b7a0 (libgio-2.0.so.0 - gtask.c: 1232) g_task_return_now
0x0000007aa6e4a6b0 (libgio-2.0.so.0 - gtask.c: 1301) g_task_return
0x0000007aa6b58400 (libqmi-glib.so.5 - qmi-dms.c: 32600) set_event_report_ready
0x0000007aa6e3642c (libgio-2.0.so.0 - gsimpleasyncresult.c: 804) g_simple_async_result_complete
0x0000007aa6e36538 (libgio-2.0.so.0 - gsimpleasyncresult.c: 816) complete_in_idle_cb
0x0000007aa6fc6390 (libglib-2.0.so.0 - gmain.c: 3444) g_main_context_dispatch
0x0000007aa6fc66c4 (libglib-2.0.so.0 - gmain.c: 4238) g_main_context_iterate
0x0000007aa6fc6a34 (libglib-2.0.so.0 - gmain.c: 4438) g_main_loop_run
0x0000005a58119274 (ModemManager - main.c: 221) main
0x0000007aa67870f8 (libc.so.6 + 0x000270f8) __libc_init_first
0x0000007aa67871c8 (libc.so.6 + 0x000271c8) __libc_start_main
0x0000005a58118aec (ModemManager + 0x000a8aec) _start
|
|
IPv4v6 (dual-stack)
To address limitations in reading IP_TYPE information (in some cases) for profile requests,
default to IPv4v6 (dual-stack) for profile requests and IPv4 only for user requests (to ensure backward compatibility)
if nothing specific is requested. This ensures network compatibility across IPv4 and IPv6 networks,
preventing potential connectivity issues in IPv6 environments.
|
|
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.
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
A new ID_MM_QMI_PREALLOCATED_LINKS udev tag, set in the NET port of
the device, allows configuring the amount of preallocated multiplexed
links that need to be created upon the first connection attempt,
regardless of the multiplexing setup method used.
If not specified by the user, 4 preallocated links are created when
using the qmi_wwan multiplexing procedure, and none for rmnet.
Previously, using preallocated links was exclusive used with the
qmi_wwan multiplexing procedure. Using preallocated links may be
useful if you want to maintain the same links across multiple
connection and disconnection loops, e.g. if running a tcpdump on a
given link interface capturing all traffic (not using preallocated
links in this case would be problematic as tcpdump cannot be requested
to run on net interfaces that don't exist yet).
|
|
|
