The timeout in this command is extremely large, because there are some
modules like the EGS5 that build the response based on the current
network registration, and that implies the module needs to be
registered. If for any reason there is no serving network where to
register, the response comes after a very long time, up to 100s.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/408
We should check if WDA is supported before running any other logic
that may change the state of the kernel or the modem. E.g. if we don't
do this as the first step, the loading of the supported kernel data
modes may end up changing the expected kernel data mode to raw-ip.
==99766== 96 (24 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 3,791 of 4,243
==99766== at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==99766== by 0x50DCAC9: g_malloc (gmem.c:106)
==99766== by 0x50F46D6: g_slice_alloc (gslice.c:1069)
==99766== by 0x50CE9F2: g_list_insert_sorted_real (glist.c:1109)
==99766== by 0x753DE92: ???
==99766== by 0x753E6D4: ???
==99766== by 0x753E897: ???
==99766== by 0x1F059D: mm_plugin_create_modem (mm-plugin.c:922)
==99766== by 0x166693: mm_device_create_modem (mm-device.c:481)
==99766== by 0x161547: device_support_check_ready (mm-base-manager.c:219)
==99766== by 0x4F03533: g_task_return_now (gtask.c:1219)
==99766== by 0x4F07078: UnknownInlinedFun (gtask.c:1289)
==99766== by 0x4F07078: g_task_return (gtask.c:1245)
It's been observed that running CPOL? would completely break the AT
port of the modules like the GIO225.
Fully disable this feature in the whole option and option-hso plugins,
by creating a new custom SIM object with the features disabled
completely, and setup as a new shared interface object.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/404
==748616== 37 bytes in 1 blocks are definitely lost in loss record 2,850 of 4,938
==748616== at 0x48435FF: calloc (vg_replace_malloc.c:1117)
==748616== by 0x249CCF: qcdm_cmd_log_config_new (commands.c:1742)
==748616== by 0x24A321: qcdm_cmd_log_config_set_mask_new (commands.c:1901)
==748616== by 0x1DAE12: modem_cdma_setup_cleanup_unsolicited_events (mm-broadband-modem.c:8643)
==748616== by 0x1DAF21: modem_cdma_setup_unsolicited_events (mm-broadband-modem.c:8671)
==748616== by 0x1AE49F: interface_enabling_step (mm-iface-modem-cdma.c:1627)
==748616== by 0x1AE680: mm_iface_modem_cdma_enable (mm-iface-modem-cdma.c:1693)
==748616== by 0x1E2DF6: enabling_step (mm-broadband-modem.c:11756)
==748616== by 0x1E204E: iface_modem_3gpp_ussd_enable_ready (mm-broadband-modem.c:11606)
==748616== by 0x4F03533: g_task_return_now (gtask.c:1219)
==748616== by 0x4F07078: UnknownInlinedFun (gtask.c:1289)
==748616== by 0x4F07078: g_task_return (gtask.c:1245)
==748616== by 0x1AA323: interface_enabling_step (mm-iface-modem-3gpp-ussd.c:702)
WWAN network devices expose link management over netlink (wwan type),
but it is not yet supported by libmbim.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
The wwan subsystem is a new bus agnostic framework exposing wwan
device and its components (ports, netdev...). It can be useful to
get the wwan device a device belongs to
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signal quality property signature of the Modem Simple interface
is not an unsigned integer, but a struct containing
an unsigned integer indicating the strength and
a boolean to indicate if the value was recently taken.
Will be set by base modem when organizing ports, similar to
net driver name. Required for fetching the TX and RX endpoint IDs
through sysfs from linux 5.14 onwards.
When querying the slots using "Slot info status", the modem expects
the slot index passed in the [0,number_slots-1] range.
But for the ModemManager API, the slot indices start at 1; i.e. they
are in the [1,number_of_slots] range.
Consider that wen reporting the current slot index using MBIM.
==252789== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==252789== Access not within mapped region at address 0x28
==252789== at 0x7D17D22: connect_reset_ready (mm-broadband-bearer-icera.c:419)
==252789== by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
==252789== by 0x17EFC6: at_command_ready (mm-base-modem-at.c:538)
==252789== by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
==252789== by 0x259423: serial_command_ready (mm-port-serial-at.c:393)
==252789== by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
==252789== by 0x252B9B: command_context_complete_and_free (mm-port-serial.c:141)
==252789== by 0x254542: port_serial_got_response (mm-port-serial.c:755)
==252789== by 0x254A78: parse_response_buffer (mm-port-serial.c:926)
==252789== by 0x254FFE: common_input_available (mm-port-serial.c:1035)
==252789== by 0x2550DE: iochannel_input_available (mm-port-serial.c:1058)
==252789== by 0x50D3F84: UnknownInlinedFun (gmain.c:3344)
==252789== by 0x50D3F84: g_main_context_dispatch (gmain.c:4062)
The whole device breaks when the CPOL? query is sent; happening
consistently all the time:
<debug> [1626211395.825257] [modem4/ttyUSB3/at] --> 'AT+CPOL=,2<CR>'
<debug> [1626211395.842156] [modem4/ttyUSB3/at] <-- '<CR><LF>OK<CR><LF>'
<debug> [1626211395.843227] [modem4/sim4] loading preferred networks...
<debug> [1626211395.845289] [modem4/ttyUSB3/at] --> 'AT+CPOL?<CR>'
<debug> [1626211401.110974] [modem4/ttyUSB3/at] unexpected port hangup!
<debug> [1626211401.111586] [modem4/ttyUSB3/at] forced to close port
<debug> [1626211401.112331] [modem4/ttyUSB3/at] closing serial port...
<debug> [1626211401.112771] [modem4/ttyUSB3/at] serial port closed
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/401
We should never run any mm_bearer_properties_set_X() operations
ourselves for the properties received by the user, or otherwise the
logic comparing the bearers will fail and we may end up creating one
bearer per connection attempt.
There are modems out there, that reuse the same vid:pid for multiple
USB layouts, so there may be port type hints that are not really
applicable in all layouts.
E.g. the EM7565 in MBIM layout uses interface #0 for the MBIM port,
while in QMI layout it uses interface #0 for the QCDM port (which is
what the port type hint included in MM states). With these rules, if
we don't bind the port type hint to TTY ports only, we would be
wrongly flagging the MBIM port as possible QCDM port:
<debug> [plugin/sierra] probes required for port cdc-wdm0: 'mbim'
<debug> [cdc-wdm0/probe] no AT/QMI/MBIM probing in possible QCDM port
<debug> [cdc-wdm0/probe] port is not AT-capable
<debug> [cdc-wdm0/probe] port is not QMI-capable
<debug> [cdc-wdm0/probe] port is not MBIM-capable
<debug> [cdc-wdm0/probe] port probing finished: no more probings needed
Avoid this, by making sure all port type hints are added exclusively
to TTY ports. It's not a perfect solution, but it's enough for the
known cases.
==636642== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==636642== at 0x5282BAC: send (in /usr/lib/libpthread-2.33.so)
==636642== by 0x4EF20AF: UnknownInlinedFun (gsocket.c:3426)
==636642== by 0x4EF20AF: g_socket_send_with_blocking (gsocket.c:3529)
==636642== by 0x4EDF176: g_output_stream_write (goutputstream.c:242)
==636642== by 0x4EDF2D4: g_output_stream_write_all (goutputstream.c:301)
==636642== by 0x4A5CDAC: endpoint_send (qmi-endpoint-qmux.c:409)
==636642== by 0x4A5B963: qmi_endpoint_send (qmi-endpoint.c:225)
==636642== by 0x4A55408: qmi_device_command_abortable (qmi-device.c:2897)
==636642== by 0x4A554C3: qmi_device_command_full (qmi-device.c:2923)
==636642== by 0x4B52664: qmi_client_nas_set_system_selection_preference (qmi-nas.c:61099)
==636642== by 0x1F6FDC: register_in_network_sssp (mm-shared-qmi.c:455)
==636642== by 0x1F71E6: mm_shared_qmi_3gpp_register_in_network (mm-shared-qmi.c:505)
==636642== by 0x19FCF0: mm_iface_modem_3gpp_register_in_network (mm-iface-modem-3gpp.c:484)
==636642== Address 0x880a3b3 is 19 bytes inside a block of size 32 alloc'd
==636642== at 0x484383F: realloc (vg_replace_malloc.c:1192)
==636642== by 0x50DC130: g_realloc (gmem.c:171)
==636642== by 0x50A067C: g_array_maybe_expand (garray.c:1009)
==636642== by 0x50A0A0C: UnknownInlinedFun (garray.c:520)
==636642== by 0x50A0A0C: g_array_append_vals (garray.c:509)
==636642== by 0x50A0A9E: g_byte_array_append (garray.c:2430)
==636642== by 0x4A4B70D: qmi_message_tlv_write_guint8 (qmi-message.c:686)
==636642== by 0x4B14CA8: __qmi_message_nas_set_system_selection_preference_request_create (qmi-nas.c:33477)
==636642== by 0x4B525B6: qmi_client_nas_set_system_selection_preference (qmi-nas.c:61087)
==636642== by 0x1F6FDC: register_in_network_sssp (mm-shared-qmi.c:455)
==636642== by 0x1F71E6: mm_shared_qmi_3gpp_register_in_network (mm-shared-qmi.c:505)
==636642== by 0x19FCF0: mm_iface_modem_3gpp_register_in_network (mm-iface-modem-3gpp.c:484)
==636642== by 0x1B0BD4: check_next_registration (mm-iface-modem-simple.c:154)
Prior to this change, a hotswap on the inactive slot would result
in reprobe of the modem. With this change, the sim object would be
updated, but no reprobe will be performed. The advantage is
1) we do not drop connections on the active slot
2) Slot status on the inactive slot is susceptible to firmware bugs.
We have seen scenarios where the inactive slot is reported as
absent/ iccid={0}, followed by a correction. We should not
reprobe the modem if our active slot hasn't changed.
Not all manufacturers expect this service to be used for the simple
purpose of reseting the modem.
It works with Sierra Wireless devices (e.g. EM7345,
XMM7160_V1.1_MODEM_01.1349.12), but it doesn't work with Cinterion
devices (e.g. mPLS62-w, XMM7160_V1.1_MBIM_NAND_ADAPT_R).
So allow plugins to disable its use entirely.
The support of autoptr for GEnumClass and GFlagsClass was introduced in
glib 2.58. To keep compatibility with glib 2.56, declare the autoptr
cleanup functions.
Fixes#397
There are modems (e.g. Nokia, Thuraya, Iridium) which don't require or
don't support power management, and therefore there is no way to
either load or update the power status.
In those modems we just assume ON is the current and only value (set
in the skeleton during initialization) and so when we attempt to
update the power state to ON during enabling, the logic should not
break.
Fix the logic by making sure the requested_power_setup() function
pointers are only checked for validity after ensuring we're not
already in the desired power state.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/398
Recent Linux kernel versions have introduced a generic WWAN subsystem
that provides various char devices for QMI, AT etc, similar to the
subsystem-specific char devices for USB or RPMSG.
The RPMSG char device for Qualcomm SoCs (e.g. MSM8916/MSM8974)
are particularly complicated to work with because they need to be
explicitly created from userspace with rpmsgexport and don't show up
automatically.
However, it turns out it's fairly simple to wrap the RPMSG subsystem
in a simple driver for the WWAN subsystem. This has several advantages:
- We can drop support for the special RPMSG char devices entirely
at some point.
- The WWAN char devices show up automatically, without having to export
them explicitly, making ModemManager work out of the box on these devices.
For now, just support using the WWAN subsystem alternatively for the
qcom-soc plugin. Later we can consider dropping the old RPMSG code.
