| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
If the user doesn't provide a specific multiplex setting, we'll
fallback to a predefined default.
For now, the default is REQUESTED.
|
|
|
|
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)
|
|
The signal handler may have been already removed during dispose of the
modem object, which is run manually through g_object_run_dispose().
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/399
|
|
|
|
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.
|
|
|
|
service
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.
|
|
|
|
Implemented for all QMI, MBIM and AT based modems. The parent reset
operation always takes priority if available.
|
|
|
|
This was required when building with GLib < 2.54, but we now require
2.56 as minimum, so it is no longer needed.
|
|
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.
|
|
indication
|
|
|
|
|
|
|
|
See log from a SARA-R410M-02B-01 before the change:
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.012330] [modem0/ttymxc4/at] --> 'AT+UBANDSEL?<CR>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.026831] [modem0/ttymxc4/at] <-- '<CR><LF>ERROR<CR><LF>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.027113] [modem0/ttymxc4/at] operation failure: 100 (Unknown error)
Feb 01 05:40:01 unit ModemManager[304]: <warn> [1612158001.027298] [modem0] couldn't load current bands: Unknown error
Backed by SARA-R4 series AT commands manual, no reference to +UBANDSEL
in the manual at all.
Log after the change:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500845] [modem0] (u-blox) support configuration found for 'SARA-R410M-02B'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500961] [modem0] (u-blox) band update requires explicit unregistration
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501052] [modem0] (u-blox) UACT based band configuration unsupported
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501141] [modem0] (u-blox) UBANDSEL based band configuration unsupported
Fixes: 437fb830c807 ("ublox,helpers: assume all SARA/LARA devices require COPS")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
|
|
The SARA-R410M-02B-01 only supports values 7 and 8, log excerpt:
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.826046] [modem0/ttymxc4/at] --> 'AT+URAT=?<CR>'
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.833596] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: (7-8),(7-8)(7-8)<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.833992] [modem0] (u-blox) unexpected AcT value: 7
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834096] [modem0] (u-blox) unexpected AcT value: 8
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834193] [modem0] couldn't load supported modes: No combinations built from +URAT=? response
The SARA-R4 series AT commands manual (and also the SARA-R5 AT commands
manual) lists them like this:
- 7: LTE Cat M1
- 8: LTE Cat NB1
After the change, log looks like this:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.490627] [modem0/ttymxc4/at] --> 'AT+URAT?<CR>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.499994] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: 7,8<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500433] [modem0] (u-blox) current allowed modes retrieved: 4g
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500561] [modem0] (u-blox) current preferred modes retrieved: 4g
Signed-off-by: Alexander Dahl <ada@thorsis.com>
|
|
Signed-off-by: Nicholas Smith <nicholas@nbembedded.com>
|
|
Calling the mm_iface_modem_update_unlock_retries function directly from
pin_set_enter_ready caused a notification to be send too early with
invalid number of attempts to unlock on MBIM modems.
The mm_iface_modem_update_unlock_retries is already called for all
modems from send_pin_ready (mm-base-sim.c).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is truly no need for a per-property mutex, using a global one
for the whole object is equally fine.
|
|
Remove unused methods, like all the variant_to_array() ones, and
reorder some others so that both header and source file have the same
order always.
|
|
This action allows us to monitor location updates as signaled via the
'Location' property, only available if location signaling has been
explicitly enabled (e.g. with --location-set-enable-signal)
|
|
Each with its expected corresponding length.
|
|
TAC is 3 bytes for NG-RAN as specified in 3GPP TS 38.413 clause
9.3.3.10 and in 3GPP TS 24.501 clause 9.10.3.8.
We'll always print it as 3 bytes in the cli output, as that's also
backwards compatible with the original 2 byte TAC in LTE.
|
|
We allow clients to receive asynchronous updates of location
information, e.g. if "location signaling" is explicitly enabled (with
the setup() method).
But if so, we should also allow clients to easily process those
asynchronous updates in the libmm-glib library, instead of requiring
them to run explicit DBus queries to refresh the location information.
These new signaled location APIs allow clients to do so; they can
enable location signaling, and then just wait for the updates to
arrive.
|
|
Rework the build_locations() method so that it doesn't take ownership
of the input dictionary. This allows us reusing this method with
dictionaries for which ownership cannot be transferred.
|
|
The properties object stored in the context is being returned as task
result; so we should make sure that object is no longer left in the
context so that it's not freed twice.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/395
|
|
|
|
|
|
|
|
|
