| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Currently, we are not increasing the reference counter of the QrtrNode
when creating a PortQmi for a QRTR port, and we are clearing the object
when disposing the port.
|
|
$ sudo ./modem-watcher-python
[ModemWatcher] ModemManager 1.16.6 service is available in bus
[ModemWatcher] /org/freedesktop/ModemManager1/Modem/0: modem managed by ModemManager [015805000283080]: foxconn (MBIM [105B:E0AB])
[ModemWatcher] /org/freedesktop/ModemManager1/Modem/0: modem state updated: disabled -> enabling (user-requested)
[ModemWatcher] /org/freedesktop/ModemManager1/Modem/0: modem state updated: enabling -> enabled (user-requested)
[ModemWatcher] /org/freedesktop/ModemManager1/Modem/0: modem state updated: enabled -> registered (unknown)
|
|
If using rmnet and IP passthrough setting in qmi_wwan, also configure
the master interface with an MTU equal to the maximum data aggregation
size.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/367
|
|
The signal definition is:
<signal name="StateChanged">
<arg name="old" type="i" />
<arg name="new" type="i" />
<arg name="reason" type="u" />
</signal>
So the first two arguments need to be adjusted.
Without this change, the test was failing for me:
(/build/source/tools/tests/.libs/lt-test-stub:77030): GLib-GObject-CRITICAL **: 15:05:35.276: ../gobject/gsignal.c:3167: value for 'gint' parameter 0 for signal "state-changed" is of type 'guint'
|
|
==4263== 747 (72 direct, 675 indirect) bytes in 3 blocks are definitely lost in loss record 5,739 of 5,787
==4263== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4263== by 0x50C6DE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50DDFF1: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50B8EB9: g_list_prepend (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x27CE4C: mm_3gpp_parse_cgdcont_read_response (mm-modem-helpers.c:1845)
==4263== by 0x1E5485: profile_manager_cgdcont_query_ready (mm-broadband-modem.c:10200)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x18605E: at_command_ready (mm-base-modem-at.c:538)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x25ADFA: serial_command_ready (mm-port-serial-at.c:393)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x254752: command_context_complete_and_free (mm-port-serial.c:141)
|
|
|
|
Use mm_obj_warn() instead.
|
|
Use mm_obj_warn() instead.
|
|
|
|
|
|
These lists were used in the corresponding TTY_BLACKLIST and
TTY_MANUAL_SCAN_ONLY filter rules, in the LEGACY and PARANOID filter
types, which are no longer supported.
The DEFAULT_ALLOWED filter rule made sense only in the LEGACY filter
type, and therefore it is also now removed, leaving the
DEFAULT_FORBIDDEN fallback rule exclusively. In other words, there is
now no way to ask ModemManager to implicitly allow TTY ports; the only
way to do that is by explicit making the TTY ports fall in one filter
rule that would allow them.
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/390
|
|
|
|
|
|
|
|
|
|
|
|
wwan qcdm port is not a serial port, calling config_fd on it
will always fail, i.e.:
ModemManager[124587]: <debug> [1619584182.125262] [wwan0p1QCDM/probe] probing QCDM...
ModemManager[124587]: <debug> [1619584182.125398] [wwan0p1QCDM/qcdm] opening serial port...
ModemManager[124587]: <debug> [1619584182.151759] [wwan0p1QCDM/qcdm] failed to configure serial device
ModemManager[124587]: <warn> [1619584182.151836] [wwan0p1QCDM/qcdm] failed to open serial device
ModemManager[124587]: <warn> [1619584182.170152] [plugin-manager] task 1,wwan0p1QCDM: error when checking support with plugin 'generic': (wwan/wwan0p1QCDM) Failed to open QCDM port: Failed to open QCDM port: -2
|
|
|
|
FIREHOSE ports are used for firmware updates which are done
independently from ModemManager, so we should ignore those ports.
A similar change was originally made by Loic Poulain here:
https://gitlab.freedesktop.org/loicpoulain/ModemManager/-/commit/32b0eb79cdbb37afe33abb72fd948be3cbaf6a2d
|
|
Recent changes in the WWAN framework in the kernel changed the WWAN
port names from e.g. "wwan0p1AT" and "wwan0p2QMI" to "wwan0at0" and
"wwan0qmi0" [1, 2]. This means that the udev rules no longer match
since AT/QMI are now lower-case and no longer at the end of the name.
However, recently additionally a "type" sysfs attribute was added
for all WWAN ports [3], which makes it much more reliable to match
the WWAN port names without relying on their exact device name.
Add some additional udev rules to apply the port hints based on the
"type" sysfs attributes. This fixes the port enumeration on newer
Linux kernels that include the aforementioned commits.
Note that we still need to keep the old udev rules for now since
Linux 5.13 does not have the "type" attribute yet.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=392c26f7f133b9f09e5f58db1ce6ef4b3b4df49f
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=f458709ff40b0d992fec496952f79c7820dd3fde
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=b3e22e10fdda8e7be3830289a4a63ae8b88d450c
|
|
Explicitly ignore the "wwan_dev" device as it is not associated with
separate ports (which is what MM needs), but with the whole device
instead.
See https://lists.freedesktop.org/archives/modemmanager-devel/2021-May/008629.html
|
|
This reverts commit 6ffe84a122b9a79a8f0951af5ee5075f16726bdd.
|
|
This message is too specific, and there are a lot of cases where it
wouldn't apply.
E.g. when a MBIM module is stuck in low power mode due to some other
reason (like hardware rfkill), this message would pop up to the users
and completely confuse them.
|
|
|
|
QLWURCs are not ignored and causes calls to be rejected in some cases
|
|
Having a switch() for the MBIM services when processing indications
forces us to update it on every new MBIM service added to libmbim,
because we build with -Wswitch-enum by default.
This warning type is extremely useful, and we should not stop using
it, so let's simplify a bit the indication handling code and skip
using a switch().
There are right now only 4 different service indications expected, so
it shouldn't be a big deal.
|
|
After fwupd upgrade with mbim-qdu method, MM sometimes generate plugin failed with the regenerated MHI driver.
This patch increases the mbim_device_open_full timeout from 30 seconds to 45 seconds to prevent such issue.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
|
|
Reported at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1371
|
|
Implement connection status reloading for MBIM based bearers.
Based on a patch by Dylan Van Assche <me@dylanvanassche.be>
|
|
The original load_connection_status() method would return an
UNSUPPORTED error if connection monitoring wasn't required (which is
the default in most QMI modems).
The new reload_connection_status() method requires the check to always
be done unconditionally.
We take most of the original logic in the load_connection_status() for
the new reload_connection_status(), and we add the UNSUPPORTED error
logic exclusively in the new load_connection_status().
|
|
Some of the AT-based connection methods don't have any way to query
connection status, or we don't have a proper implementation for those
yet. Ignore the reload operation in all those.
|
|
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Cinterion plugin.
|
|
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Sierra plugin.
|
|
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the Novatel LTE plugin.
|
|
The load_() method is used for connection monitoring; while the
reload_() method is used to sync connection status after a
suspend/resume operation. The same method can be used for both things
in the case of AT+CGACT? based modems.
|
|
There is no input cancellable in the method, so the GTask will never
get cancelled from the outside.
|
|
Do not launch N checks for N bearers and ignore their result. Instead,
go one by one, and report errors one by one.
|
|
Just triggering a connection status reload won't change the actual
bearer object state.
We change the signature of the reload_connection_status_finish()
method so that it returns the actual reloaded bearer connection
status, and so both the load_ and reload_ methods can be implemented
with exactly the same method, something that was not possible before.
Once we get the new connection status reloaded, we apply it in the
bearer object only if it's DISCONNECTED (and it wasn't DISCONNECTED
before). This should cover the true real case we're interested in, and
nothing else (i.e. we won't overcomplicate the logic attempting to
handle disconnected->connected transitions detected in the sync()
operation).
|
|
If we called the class reload_connection_status() method, we should
call the class reload_connection_status_finish() as well.
|
|
|
|
Refresh connection status on resume to confirm
that the connection bearers are still valid.
|
|
There is no input cancellable in the method, so the GTask will never
get cancelled from the outside.
|
|
when mm_iface_modem_refresh_signal() is called, we'll restart the
signal quality refresh logic already, there is no need to request
an enforced start.
The enforced start was also modifying ctx->enabled unconditionally,
which is really not ok. This logic would be enabled only when we're
registered, and that logic is fine, no need to change that.
|
|
We made sure that the after resume synchronization was only started on
modems that had been enabled (and so unlocked). If we detect a locked
SIM card during the sync operation, it's either because the SIM card
was swapped, or because the modem was fully shutdown during the
suspension (and so the SIM requires SIM-PIN again).
Either way, we cannot sync the state cleanly at this point, we must
trigger a full modem reprobe in order to move back the modem state to
Locked.
|
|
|
|
|
|
Refresh signal strength and access technologies,
check for SIM swaps, and check if the SIM is locked.
The modem may have switched to a different
access technologies or have a different signal strength
when resuming. Moreover, the user may swap or remove
the SIM when suspended.
|
|
|
