Age | Commit message (Collapse) | Author |
|
When processing QMI and MBIM messages to report domain registration
updates, we should do that altogether so that we don't report bogus
transitions to idle if the registration state switches from one domain
to another.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/629
|
|
|
|
According to 3GPP Rel16.3, 38104, band NGRAN-53 is supported.
Band info as below:
n53 2483.5 MHz - 2495 MHz, TDD
Signed-off-by: Slark Xiao <slark_xiao@163.com>
|
|
have eSIM without profiles
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/630
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
EM120/160 uses QCDM port for firmware updates. fwupd lists all known
ports from ModemManager and uses QCDM port to reboot the modem into
the firmware download mode.
|
|
For SDX55 and SDX65 can identify the corrrect plugin(cinterion), and the plugin is updated to support the wwan subsystem.
|
|
|
|
|
|
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.
|
|
We setup all output variables with g_autoptr() 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.
|
|
Currently, supported band AT query #BND=? is failing with LM9x0 because
it expects BND 4G decimal format instead than hexadecimal.
Adding also LN920 and FN980 for completeness. They do not fail right now
because they have also "4g band extended" which format is always
hexadecimal.
|
|
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.
|