aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-10-29broadband-modem: don't assert Modem interface skeleton during enablingAleksander Morgado
There is no guarantee that during an enabling operation the skeleton for the Modem interface unconditionally exists, e.g. the modem may have been flagged as invalid and untracked from DBus during the operation. Just remove the assertion, because mm_iface_modem_enable() will already cleanly fail if the skeleton object is not found. Thread 0 (crashed), 0 libc.so.6!__pthread_kill_implementation [pthread_kill.c : 44 + 0x0], 1 libc.so.6!raise [raise.c : 26 + 0xb], 2 libc.so.6!abort [abort.c : 79 + 0xa], 3 libglib-2.0.so.0!g_assertion_message [gtestutils.c : 3450 + 0x5], 4 libglib-2.0.so.0!g_assertion_message_expr [gtestutils.c : 3476 + 0x14], 5 ModemManager!enabling_step [mm-broadband-modem.c : 0 + 0x7], 6 libgio-2.0.so.0!g_task_return_now [gtask.c : 1309 + 0x5], 7 libgio-2.0.so.0!g_task_return [gtask.c : 1378 + 0x8], 8 ModemManager!parent_enabling_started_ready [mm-broadband-modem-mbim.c : 3239 + 0xd], 9 libgio-2.0.so.0!g_task_return_now [gtask.c : 1309 + 0x5], 10 libgio-2.0.so.0!complete_in_idle_cb [gtask.c : 1323 + 0x5], 11 libglib-2.0.so.0!g_main_dispatch [gmain.c : 3460 + 0x2],
2024-10-29quectel: fix crash when parsing +CTZU=? responseAleksander Morgado
The logic should consider that mm_parse_uint_list() may return NULL without setting the output GError, in the case where an empty string is given. This should ideally be changed in the mm_parse_uint_list() itself, but that approach is not trivial as the method is being used in multiple different places. This change exclusively tries to solve this crash. 0x000057435d315eca (ModemManager - mm-shared-quectel.c: 1060) ctzu_test_ready 0x00007eea3d019e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now 0x00007eea3d018e50 (libgio-2.0.so.0 - gtask.c: 1378) g_task_return 0x000057435d268eab (ModemManager - mm-base-modem-at.c: 544) at_command_ready 0x00007eea3d019e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now 0x00007eea3d018e50 (libgio-2.0.so.0 - gtask.c: 1378) g_task_return 0x000057435d318a18 (ModemManager - mm-port-serial-at.c: 350) serial_command_ready 0x00007eea3d019e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now 0x00007eea3d018e50 (libgio-2.0.so.0 - gtask.c: 1378) g_task_return 0x000057435d31c7bd (ModemManager - mm-port-serial.c: 734) port_serial_got_response 0x000057435d31cc3e (ModemManager - mm-port-serial.c: 911) parse_response_buffer 0x000057435d31cc3e (ModemManager - mm-port-serial.c: 1028) common_input_available 0x00007eea3d16591b (libglib-2.0.so.0 - gmain.c: 3460) g_main_dispatch 0x00007eea3d16591b (libglib-2.0.so.0 - gmain.c: 4200) g_main_context_dispatch 0x00007eea3d165c37 (libglib-2.0.so.0 - gmain.c: 4276) g_main_context_iterate 0x00007eea3d165eb5 (libglib-2.0.so.0 - gmain.c: 4479) g_main_loop_run 0x000057435d25f5bf (ModemManager - main.c: 236) main 0x00007eea3c980705 (libc.so.6 - libc_start_call_main.h: 58) __libc_start_call_main 0x00007eea3c9807c1 (libc.so.6 - libc-start.c: 360) __libc_start_main_impl 0x000057435d25ef10 (ModemManager + 0x000b3f10) _start 0x00007ffcc0b5d517
2024-10-24bearer-qmi: use QMI port to check for connection status pollingStig M. Baugstø
Signed-off-by: Stig M. Baugstø <1129097-stigma@users.noreply.gitlab.freedesktop.org>
2024-10-24simtech: disable QMI PCO for SIM7100E preventing delayed modem crashStig M. Baugstø
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/884 Signed-off-by: Stig M. Baugstø <1129097-stigma@users.noreply.gitlab.freedesktop.org>
2024-10-24cellient: new generic plugin for Cellient modems with optional QMIStig M. Baugstø
Simple plugin handling Cellient (vid 0x2692) modems. Optional QMI through the WITH_QMI compile flag. Disables QMI WDS PCO for the Qualcomm-branded MPL200 by setting the ID_MM_QMI_PCO_DISABLED udev tag, effectively preventing a modem crash. Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/842 Signed-off-by: Stig M. Baugstø <1129097-stigma@users.noreply.gitlab.freedesktop.org>
2024-10-24bearer-qmi: add udev device tag ID_MM_QMI_PCO_DISABLED to disable PCOStig M. Baugstø
Some modems like the Qualcomm-based Cellient MPL200 and SimTech SIM7100E will crash some time after requesting operator reserved PCO. The new udev tag ID_MM_QMI_PCO_DISABLED disables the PCO settings request when set, indirectly disabling PCO. Signed-off-by: Stig M. Baugstø <1129097-stigma@users.noreply.gitlab.freedesktop.org>
2024-10-21device: log vid:pid information at msg levelAleksander Morgado
The vid:pid information of a given device is useful information, especially when analyzing user provided logs. This change makes the vid:pid information be included at msg level in the same message that reports the plugin in use. It also removes some redundant messages.
2024-10-21iface-modem-3gpp: fix crash when trying to set unknown power stateAleksander Morgado
Certain QMI-based USB modems will report an "unknown" power state upon boot, before our first attempt to set one: $ sudo qmicli --dms-get-operating-mode -d /dev/cdc-wdm0 -p [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'unknown' HW restricted: 'no' Due to this, the logic trying to recover the previous power state during an attach settings update would end up asserting: [modem3] set initial EPS bearer settings state (3/5): recover previous power state ** ERROR:../src/mm-iface-modem.c:4554:mm_iface_modem_set_power_state: code should not be reached Bail out! ERROR:../src/mm-iface-modem.c:4554:mm_iface_modem_set_power_state: code should not be reached Aborted This is a rare case, and instead of handling it in the QMI specific implementation, we can try to fix it in a safer way directly in the logic that handles the attach settings update. If we ever detect that the reported power state is "unknown", we will default it to "on" while emitting a warning.
2024-10-17plugin-manager: disallow port additions to an already cancelled device contextAleksander Morgado
If the DeviceContext is cancelled, we remove it from the list of tracked DeviceContexts in the MMPluginManager, so that new port additions happening at the same time don't end up being added to it. This should allow an early cancellation of the DeviceContext without asserting on g_assert (!device_context->extra_probing_time_id) as there is no chance that a new port addition has reseted the extra probing time timeout. 0x00007c1154f16abf (libc.so.6 - pthread_kill.c: 44) __pthread_kill_implementation 0x00007c1154ecbf0c (libc.so.6 - raise.c: 26) raise 0x00007c1154eb74aa (libc.so.6 - abort.c: 79) abort 0x00007c11556c08a9 (libglib-2.0.so.0 - gtestutils.c: 3450) g_assertion_message 0x00007c11556c091d (libglib-2.0.so.0 - gtestutils.c: 3476) g_assertion_message_expr 0x00005897d1ed6e7b (ModemManager - mm-plugin-manager.c: 805) device_context_unref 0x00005897d1ed6ab9 (ModemManager - mm-plugin-manager.c: 163) common_async_context_free 0x00005897d1ed5dd6 (ModemManager - mm-plugin-manager.c: 1136) port_context_run_ready 0x00007c1155550e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now 0x00007c115554fe50 (libgio-2.0.so.0 - gtask.c: 1378) g_task_return 0x00007c115555047b (libgio-2.0.so.0 - gtask.c: 2022) g_task_return_new_error 0x00005897d1ed581a (ModemManager - mm-plugin-manager.c: 296) port_context_complete 0x00005897d1ed6259 (ModemManager - mm-plugin-manager.c) plugin_supports_port_ready 0x00007c1155550e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now 0x00007c1155550eb9 (libgio-2.0.so.0 - gtask.c: 1323) complete_in_idle_cb 0x00007c115569c91b (libglib-2.0.so.0 - gmain.c: 3460) g_main_dispatch 0x00007c115569c91b (libglib-2.0.so.0 - gmain.c: 4200) g_main_context_dispatch 0x00007c115569cc37 (libglib-2.0.so.0 - gmain.c: 4276) g_main_context_iterate 0x00007c115569ceb5 (libglib-2.0.so.0 - gmain.c: 4479) g_main_loop_run 0x00005897d1e715bf (ModemManager - main.c: 236) main 0x00007c1154eb7705 (libc.so.6 - libc_start_call_main.h: 58) __libc_start_call_main 0x00007c1154eb77c1 (libc.so.6 - libc-start.c: 360) __libc_start_main_impl 0x00005897d1e70f10 (ModemManager + 0x000b3f10) _start 0x00007ffd5acc5057 Manually reproducing this issue was challenging, so adding here the steps taken, for reference. This is with ModemManager running with --no-udev (i.e. port additions reported via mmcli). The key to reproduce the problem is the different timing between the port additions and removals of the three ttyACM ports. COUNT=1 while ((COUNT < 10000)); do echo "$COUNT..." COUNT=$((COUNT + 1)) ( sudo mmcli --report-kernel-event="name=ttyACM0,subsystem=tty,action=add" TIMEOUT="0.0$(((RANDOM % 10) + 1))" sleep $TIMEOUT sudo mmcli --report-kernel-event="name=ttyACM0,subsystem=tty,action=remove" ) & ( sudo mmcli --report-kernel-event="name=ttyACM1,subsystem=tty,action=add" TIMEOUT="0.0$(((RANDOM % 10) + 1))" sleep $TIMEOUT sudo mmcli --report-kernel-event="name=ttyACM1,subsystem=tty,action=remove" ) & ( sudo mmcli --report-kernel-event="name=ttyACM2,subsystem=tty,action=add" TIMEOUT="0.0$(((RANDOM % 10) + 1))" sleep $TIMEOUT sudo mmcli --report-kernel-event="name=ttyACM2,subsystem=tty,action=remove" ) & TIMEOUT="0.0$(((RANDOM % 10) + 1))" sleep $TIMEOUT COUNT=$((COUNT + 1)) done
2024-10-17cinterion: fix propagating NULL GErrorAleksander Morgado
(ModemManager:2925): GLib-CRITICAL **: 09:21:32.082: g_propagate_error: assertion 'src != NULL' failed (ModemManager:2925): GLib-GIO-CRITICAL **: 09:21:32.083: g_task_return_error: assertion 'error != NULL' failed` Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/916
2024-10-16device: fix double free of the GDBusConnectionAleksander Morgado
Fixes a16ad2757dc5c9b94aeb0e4276a4eb3d0007a729
2024-10-07api,core,mmcli: Add new 'API' support to set-default-storage for SMSAkula Susmitha
API support has been added to set default storage for SMS. Changes were made to get, set the deafult storage value.
2024-09-30ublox: remove custom power operation synchronization logicAleksander Morgado
These are already synchronized at interface level, so there is already a guarantee that they won't happen at the same time.
2024-09-30quectel: remove custom power operation synchronization logicAleksander Morgado
The power up and down operations are already synchronized at interface level, so there is already a guarantee that they won't happen at the same time. For the reset and power off operations, it is assumed that the modem will either reset or power off, so there should be no need to sync those operations with others, as the modem object will eventually go away altogether in both cases.
2024-09-30device: don't attempt to export if bus connection has been lostAleksander Morgado
E.g. if aborting the initialization sequence.
2024-09-30base-modem: override disable operations done before modem object removalAleksander Morgado
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
2024-09-30base-modem: new 'override' operation lock typeAleksander Morgado
If a request to lock the operation with the override type arrives, all pending operations will be immediately cancelled, and no new lock requests will be allowed.
2024-09-30iface-[modem|modem3gpp]: operation lock in all operations that change stateAleksander Morgado
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
2024-09-30base-modem: synchronize initialize/enable/disable/sync operationsAleksander Morgado
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
2024-09-30base-modem: remove support for parallel enable/disable operationsAleksander Morgado
Follow up changes will introduce support to run exclusive enable and disable operations, effectively ensuring that only one enabling or disabling task is processed at any given time, so the support for completing parallel operations with the same result is no longer needed. That logic was anyway flawed, as it did not consider complex cases like a disable request received between two enable requests, the order of incoming requests was not maintained. The main reason for adding the parallel enable/disable operation logic was for the case where 2 separate users tried to enable the modem at the same time. In that case, we did not want to run 2 separate enabling operations from scratch, and completing one would complete the second one as well. With the new operation lock logic, the same result is achieved, as the 2nd enabling operation would find the modem already enabled, if the 1st one succeeded. This removal is done before introducing the new exclusive operation support in the enable/disable path in order to make it easier and more consistent with other operations that will also be included in the synchronization.
2024-09-30base-modem: add setup to allow exclusive operationsAleksander Morgado
There are certain operations that cannot be run in parallel, e.g. one should not disable and bring the modem to low power mode while there are also incoming requests to enable the modem. This type of errors will typically happen when multiple DBus clients are trying to use the same modem at the same time for different purposes. We do not have any way to have DBus clients take exclusive ownership of a given modem object, so the best we can do for now is trying to synchronize operations that cannot be run together, preserving the order in which they arrived, and running them one by one.
2024-09-30broadband-modem: update modem state before disabling task is completedAleksander Morgado
The modem state property update was happening at disabling task context free time, after the actual task completion has happened. Avoid wrong assumptions on the modem state value in operations scheduled after the task completion, in the same way as done in the enabling sequence.
2024-09-30broadband-modem: update modem state before enabling task is completedAleksander Morgado
The modem state property update was happening at enabling task context free time, after the actual task completion has happened. Due to this, scheduling a new enable request right after finishing one would end up with the logic asserting, as the new enable operation would be scheduled while the modem was still reporting "enabling" state. ModemManager[7673]: <inf> [1722359278.131123] [modem0] processing user request to enable modem... ** ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached Bail out! ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached Aborted
2024-09-25sim: add common helpers to parse operator name and mnc lengthMichal Mazur
2024-09-25sim-mbim: read operator name and id from SIM EF filesMichal Mazur
Currently the SIM operator name and code are read using the "Home Provider" query operation which may perform network communication to get name provided by operator. This may take long to complete or even timeout. Solution is to read name and id from SIM card.
2024-09-24plugins/quectel: support modem power operations for AT-based devicesDan Williams
Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-18qrtr-bus-watcher: Increase delay for probingKamesh Relangi
Sometimes Qualcomm modem is not detected because modem is up after initial probing is completed. Increase in wait time for probing to ensure that modem is up.
2024-09-17helpers: consolidate some uses of mm_kernel_device_get_subsystem()Dan Williams
Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-17port-probe: restart AT probing if "NO CARRIER" is received during QCDM probingDan Williams
If the system and modem are independently powered, a system restart may leave one of the modem's AT ports in PPP mode. On restart this may cause AT probing to fail. The modem may terminate PPP after receiving bogus HDLC frames from QCDM probing (since PPP also uses HDLC framing), and return "NO CARRIER". We can use this to restart AT probing now that PPP is down and auto-detect the expected additional AT ports. Feb 08 20:22:53 ModemManager[385]: <debug> [1675887773.887574] [ttyUSB2/at] <-- '\8\158\239~' Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.215054] [ttyUSB2/at] <-- '\8\214\137~' Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.851349] [ttyUSB2/at] <-- '\8\250\177~' Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.576776] [ttyUSB2/at] <-- '\8\168u~' Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.612694] [ttyUSB2/at] <-- '\8w\25~' Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.862886] [ttyUSB2/at] <-- '\8!&~' Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.614747] [ttyUSB2/at] <-- '\8%\254~' Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686207] [ttyUSB2/probe] port is not AT-capable Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686447] [ttyUSB2/probe] probing QCDM... Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.725483] [ttyUSB2/qcdm] --> 7e 00 78 f0 7e Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.880941] [ttyUSB2/qcdm] <-- 0d 0a 4e 4f 20 43 41 52 52 49 45 52 0d 0a Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-17port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIMDan Williams
Open the AT port from the regular port probe flow rather than doing that one-off at the beginning of probing. That lets us re-open the AT port later if needed, based on QCDM/QMI/MBIM probing results. Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-17port-probe: consolidate serial port closure and cleanupDan Williams
Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-16cinterion: implement FDL update methodLukas Voegl
Adds AT^SFDL based Firmware Download as an update method for supported Cinterion modems. Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
2024-09-11broadband-modem-mbim: log hex value of IP type if unknownAleksander Morgado
The L850 seems to report 0xFFFFFFFF as MbimContextIpType value, which is not a correct value. Instead of printing "(none)" (the default used by glib when trying to print a NULL pointer as a string), make it so that we end up printing the actual numeric value in hex. <dbg> [modem0] 'home' settings found at configuration index 0 <dbg> [modem0] 'non-partner' settings found at configuration index 1 <dbg> [modem0] 'partner' settings not found <dbg> [modem0] updates in the home LTE attach configuration settings: <dbg> [modem0] ip type: 'unknown (0xffffffff)' -> ''ipv4v6' <dbg> [modem0] updates in the partner LTE attach configuration settings: <dbg> [modem0] none (skipped) <dbg> [modem0] updates in the non-partner LTE attach configuration settings: <dbg> [modem0] none
2024-09-11broadband-modem-mbim: update all home/partner/non-partner LTE attach settingsAleksander Morgado
Instead of updating the attach settings associated with the home network, update all three to the same values, so that network attach while roaming uses the same settings as in home. This is a major change in behavior; if there is ever a need to roll back to the old behavior because a given device doesn't support this, we can provided device-specific behaviors using the load_set_initial_eps_bearer_settings_mask() virtual method.
2024-09-11fibocom: L850 specific hack when using an AT&T 310280 SIM cardAleksander Morgado
L850 modems running a firmware version less than 18500.5001.0.7 and using AT&T SIM cards with MCCMNC 310280 do not support specifying "partner" settings in the MBIM operation to set the LTE attach configuration.
2024-09-11broadband-modem-mbim: rework the logic to set LTE attach configurationAleksander Morgado
The ModemManager API provides a single method to update the attach settings used in LTE registration, but in the MBIM protocol there are three different distinct configurations associated with that operation. Until now we have exclusively updated the "home" settings, leaving the "partner" and "non-partner" settings untouched (i.e. we loaded the existing settings for these sections, and used the same ones when providing our update operation). Unfortunately, this logic does not fit all needs. Some modems will require all 3 elements to be unconditionally updated, and some other modems may need to fully skip one of the configuration sections. The rework done in this commit does not change the behavior, but provides the ability for subclasses to modify how the operation is done, via a set of flags that is provided on each update attempt (as sometimes the behavior is operator-specific).
2024-09-11broadband-modem-mbim: rework home settings lookup in LTE attach config responseAleksander Morgado
We look for the home settings, but also allow to optionally lookup for the partner and non-partner settings, logging in each case if we find anomalies (e.g. if not found or if found duplicated entries).
2024-09-11modem-helpers-mbim: minor coding style fixAleksander Morgado
2024-09-10tests: test mm_split_string_groups()Dan Williams
Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-10modem-helpers: remove duplicate includeDan Williams
Signed-off-by: Dan Williams <dan@ioncontrol.co>
2024-09-09mm-sms-list: tag dbg messages with base sms identifierKyle Evans
This helps identify which base sms the message belongs to. Previous [modem0/sms-list] found existing multipart SMS object with reference '126': adding new part New [modem0/sms0] found existing multipart SMS object with reference '126': adding new part Signed-off-by: Kyle Evans <kvans32@gmail.com>
2024-09-09sms-part-3gpp: add the message timestamp in dbgKyle Evans
This aids in determining the age of messages stuck in receiving. Signed-off-by: Kyle Evans <kvans32@gmail.com>
2024-09-09mm-base-sms: cmp by reference & numberKyle Evans
Messages from different senders can have the same reference. Stale messages from the same sender can also conflict. Consider the number of the sender and also the max parts when assigning parts to a base sms. Ref 3gpp specification section 9.2.3.24.1 Fixes #757 Signed-off-by: Kyle Evans <kvans32@gmail.com>
2024-09-09quectel: implement DFOTA update methodLukas Voegl
2024-09-09Quectel: Fix obtaining incorrect module namesmank.wang
2024-09-09plugin,rolling: Update RW135 udev rules.Vanillan Wang
2024-08-29mtk: never reload TX/RX stats in FM350Aleksander Morgado
The device always reports empty TX/RX values so there is no point in periodically asking. The logic to poll for stats is kept in place only if the device requires the IP packet filters removal hack.
2024-08-23fibocom: NL668 ttys are managed by the option driverAleksander Morgado
So they are ttyUSB instead of ttyACM.
2024-08-23fibocom: add L850 AT port hintsAleksander Morgado
Just so that we make sure no other probing type is tried with them.
2024-08-21modem-helpers-qmi: map the DUN/tethering APN typeAleksander Morgado
libqmi version is bumped to 1.35.6, which is the unstable tag that includes the new symbols.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-06-08 08:34:23 +0000