| Age | Commit message (Collapse) | Author |
|---|
|
character
|
|
1) Not every allowed GSM7 character in UTF-8 incoding takes one
byte. Some (for example, 'à') take several bytes in input string, but
signle byte in GSM7.
2) Extended characters in GSM7 encoding take two bytes.
Otherwise for example sending following SMS fails:
```
mmcli -m a --messaging-create-sms="text='[wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww',number='+XXXXXXXXXXX'"
Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/99
mmcli --send -s 99
error: couldn't send the SMS: 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.WmsEncoding: Couldn't write SMS part: QMI protocol error (58): 'WmsEncoding''
```
```
mmcli -m a --messaging-create-sms="text='|àààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààà',number='+XXXXXXXXXXX'"
Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/72
mmcli --send -s 72
error: couldn't send the SMS: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InvalidArgs: Couldn't convert UTF-8 to GSM: input UTF-8 validation failed'
```
|
|
|
|
|
|
This would be the application id that refers to the active SIM card.
|
|
Get PCO information after the call is established
by using get runtime settings request
Register for Extended IP configuration Indication
If PCO is changed we get the indication and refetch
the pco information from modem
Send the PCO info using 3gpp_update_pco_list
|
|
|
|
|
|
We setup all output variables with g_autofree and then use
g_steal_pointer() to return the needed ones.
|
|
We setup all output variables with g_autofree and then use
g_steal_pointer() to return the needed ones.
|
|
The behavior of GRegex changed in 2.73.2 once it was ported from pcre1
to pcre2. In some cases it was made more strict, which is fine, in
other cases it exposed some change in how it behaves on certain
matches that is not extremely clear whether it's ok or not.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621
Either way, one thing that was assumed was that initializing all
GRegex/GMatchInfo variables to NULL and making sure they're NULL
before they're initialized by glib (especially the GMatchInfo) was a
good and safer approach.
So, whenever possible, g_autoptr() is used to cleanup the allocated
GMatchInfo/GRegex variables, and otherwise, g_clear_pointer() is used
to ensure that no free/unref is attempted unless the given variable is
not NULL, and also so that the variable is reseted to NULL after being
disposed.
|
|
Access technology and location properties are updated if modem is in
registered state.
Cache and update them when processing DSD system status indication.
|
|
Looks like pcre2 (used since glib 2.73.2) requires EOLs to match if
G_REGEX_NEWLINE_CRLF is explicitly used. The tests are updated
accordingly, because the modem responses will anyway have the EOLs
as well.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729#note_1544130
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
|
|
Passed undetected when glib2 was using pcre1, it triggers an error now
with pcre2.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729#note_1542038
Reported and fix suggested by: Marco Trevisan (Treviño) <mail@3v1n0.net>
|
|
Modem could be in 'registered' state if CS is 'attached',
but packet service state might be 'detached'.
Check if packet service state needs to be updated in
update_registration_state(), even if registration state is same.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/618
|
|
|
|
Fixes 3238ccdbb29e86acd2b3e5c0e45bee84f9da94b4
|
|
|
|
==10719== Invalid free() / delete / delete[] / realloc()
==10719== at 0x4897D88: free (vg_replace_malloc.c:872)
==10719== by 0x52F091B: g_free (gmem.c:220)
==10719== by 0x530C36B: g_slice_free1 (gslice.c:1185)
==10719== by 0x52D632B: g_error_free (gerror.c:872)
==10719== by 0x192DBF: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x192DBF: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x192DBF: sync_ready (mm-base-modem.c:671)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x50AAA4F: g_task_return_new_error (gtask.c:1944)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x1AB86B: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4644)
==10719== Address 0x910bf30 is 0 bytes inside a block of size 16 free'd
==10719== at 0x4897D88: free (vg_replace_malloc.c:872)
==10719== by 0x52F091B: g_free (gmem.c:220)
==10719== by 0x530C36B: g_slice_free1 (gslice.c:1185)
==10719== by 0x52D632B: g_error_free (gerror.c:872)
==10719== by 0x17565F: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x17565F: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x17565F: base_modem_sync_ready (mm-base-manager.c:737)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x192DAB: sync_ready (mm-base-modem.c:674)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x50AAA4F: g_task_return_new_error (gtask.c:1944)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== Block was alloc'd at
==10719== at 0x48952CC: malloc (vg_replace_malloc.c:381)
==10719== by 0x52F3EF3: g_malloc (gmem.c:127)
==10719== by 0x530CD27: g_slice_alloc (gslice.c:1074)
==10719== by 0x530D2B7: g_slice_alloc0 (gslice.c:1100)
==10719== by 0x52D5E7B: g_error_allocate (gerror.c:710)
==10719== by 0x52D690F: UnknownInlinedFun (gerror.c:724)
==10719== by 0x52D690F: g_error_new_valist (gerror.c:766)
==10719== by 0x50AAA43: g_task_return_new_error (gtask.c:1941)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x1AB86B: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4644)
==10719== by 0x1AB9A3: UnknownInlinedFun (mm-iface-modem.c:4543)
==10719== by 0x1AB9A3: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4639)
|
|
Found during code review.
|
|
Modem reports 2G+3G+4G+5G current modes, while 2G is not supported.
Consider device capabilities in deciding current modes.
|
|
|
|
|
|
|
|
Multiplexing currently does not work correctly for BAM-DMUX because
ModemManager reuses the same WDS client for all data points. A second
bearer can be created but it effectively disables the first one.
Fix this similar to the existing checks for the mux-id by including the
endpoint type and number in the QMI client flags.
|
|
At the moment the endpoint type/number is chosen based on the QMI
control port. The assumption is that multiplexing is implemented using
an additional protocol layer (e.g. QMAP) or that each network interface
has its own QMI control port.
This is not necessarily the case for BAM-DMUX. To use the built-in
multiplexing the WDS client must be bound to the correct data port.
This works already for older firmware versions using "Bind Data Port"
(SIO port numbers), but not for newer ones using "Bind Mux Data Port"
(endpoint type/interface numbers).
Make it work for newer firmware versions as well by choosing the
endpoint type/number based on the data port similar to the existing
implementation for SIO port numbers.
Note: The correct endpoint interface number is currently only used for
the steps in mm-bearer-qmi. Ideally more refactoring should be done in
mm-port-qmi to call WDA Set Data Format for each of the endpoints.
In practice it usually works fine without because the data format is
set correctly by default.
|
|
Now that peek_port_qmi_for_data_mhi() is a separate function it becomes
obvious that it looks different from all the others: There is no check
that a QMI port was actually found.
Add it similar to the one used for qmi_wwan.
|
|
peek_port_qmi_for_data() is currently quite confusing to read because it
mostly covers qmi_wwan while the mhi_net case returns early. Split this
up into separate functions per driver to make it less confusing, similar
to the variant in mm-broadband-modem-qmi-qcom-soc.
No functional change.
|
|
"Bind Data Port" does not work correctly on newer platforms with
BAM-DMUX (e.g. MSM8909). It returns "device unsupported" even for
valid SIO port numbers.
As an alternative, it seems to be possible to use the newer "Bind *Mux*
Data Port" instead. This works even when QMAP multiplexing is disabled
(using WDA "Set Data Format"). In this case the mux-id seems to be
entirely ignored and can be a dummy value such as MUX_ID_UNBOUND.
Implement this by checking for the error code of "Bind Data Port"
and fallback to "Bind Mux Data Port" instead.
The important part in this case is that the endpoint type and interface
number are set correctly. At the moment this works only for the "wwan0"
interface because the endpoint information is currently maintained
globally as part of the QMI control port instead of being handled
separately per data/net port. Further refactoring is needed to enable
multiplexing on these platforms.
|
|
At the moment the endpoint type and number for the QMI WDA calls are
chosen based on the subsystem of the QMI control port. This does not
work correctly for some configurations:
- SUBSYS_QRTR currently implies ENDPOINT_TYPE_EMBEDDED, but this is
only valid for QRTR+IPA configurations. For QRTR+BAM-DMUX the
correct type is ENDPOINT_TYPE_BAM_DMUX.
- SUBSYS_WWAN currently implies ENDPOINT_TYPE_PCIE, but there is
already a comment that mentions that this selection works only for
MHI/PCIe modems. SUBSYS_WWAN is also used by RPMSG+BAM-DMUX
configurations in which case the correct type is also
ENDPOINT_TYPE_BAM_DMUX.
Looking closer at these cases suggests that the endpoint type actually
refers to the data/net port and not the control port. It is more
reliable choose it based on the network driver and not the subsystem
of the control port.
Address this partially by choosing the endpoint type based on the
net_driver. Choosing the endpoint interface number correctly requires
more refactoring since most of the logic is currently handled globally
for a QMI control port, while it's actually specific to the chosen
data/net port in some cases (e.g. multiple BAM-DMUX network interfaces).
|
|
mm-dispatcher-fcc-unlock.c:100:27: warning: unused variable 'error' [-Wunused-variable]
g_autoptr(GError) error = NULL;
^
|
|
mm-broadband-modem-mbim.c:8525:30: warning: unused variable 'message' [-Wunused-variable]
g_autoptr(MbimMessage) message = NULL;
^
mm-broadband-modem-mbim.c:8582:29: warning: unused variable 'message' [-Wunused-variable]
g_autoptr(MbimMessage) message = NULL;
^
|
|
mm-broadband-modem.c:10703:23: warning: unused variable 'cmd' [-Wunused-variable]
g_autofree gchar *cmd = NULL;
^
|
|
Since 1.18 the user can request a different APN type during the
connection attempt, which translates into a different context type in
the actual MBIM Connect Set request. Therefore, the context type of a
given connection is no longer always INTERNET.
Matching by the session id to report disconnections should be more
than enough, which also helps to cover the case where the modem
doesn't report the original context type used during the
attempt (e.g. reporting NONE unconditionally).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/614
|
|
|
|
|
|
mm-sleep-monitor-powerd.c: In function ‘signal_cb’:
mm-sleep-monitor-powerd.c:81:14: error: unused variable ‘is_about_to_suspend’ [-Werror=unused-variable]
81 | gboolean is_about_to_suspend;
| ^~~~~~~~~~~~~~~~~~~
mm-sleep-monitor-powerd.c: In function ‘on_pd_proxy_acquired’:
mm-sleep-monitor-powerd.c:100:11: error: unused variable ‘owner’ [-Werror=unused-variable]
100 | char *owner;
| ^~~~~
|
|
Fixes 86f6d3351351f7143a7f1c5fb90ddb465089ac69
|
|
The log level of the libraries was not honoring the log level
configured in MM, so we would see debug messages reported even if the
default log level configured was INFO or MSG.
The format of the logs emitted by the libraries was also not following
the format of the rest of MM logs, e.g. they would not include timing
info in the logs which would make it hard to follow certain event
transitions.
Make the libraries logging use the ModemManager logging method, to fix
all those issues.
|
|
|
|
The SIM slots ptr array should have a proper GDestroyNotify, so that
whenever the array is unref-ed as part of the modem disposal logic,
the SIM objects (and the modem object references they keep) are also
unref-ed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/571
|
|
Port to using g_autoptr() so that we avoid the gotos.
|
|
The skeleton property will be update automatically as they're bound.
|
|
|
|
We provide a consolidated method to update the PS/EPS/5GS registration
states, based on the actual state reported via NAS and the availabiity
or not of the DSD data RAT.
On this consolidated method, we now force the IDLE state for every
case where it would have been HOME/ROAMING if the data RAT reported
via the DSD service is unknown. This includes not only transitions
into the HOME/ROAMING state, but also transitions to unknown data RAT.
|
|
|
|
'SetPacketServiceState()'
|
|
for PS domain
"registered" state should not wholly depend on the PS/EPS/5GS domain
state reported by NAS.
It should listen to DSD system status for availabilty of data network
at modem before moving to 'registered' state".
|
|
A failure loading IMSI or ICCID (unless for the UNSUPPORTED case)
could be an indication that there is no SIM.
Ideally, the logic checking if a SIM swap happened should have checked
first if there is a SIM card in the slot, and only if there is one go
on to try to load IMSI or ICCID.
|
|
|
