Age | Commit message (Collapse) | Author |
|
SIM A7600E-H sends only 3 parameters in CGDCONT read response (+CGDCONT: 1,"IP","nate.sktelecom.com").
The parsing regex requeres 4 parameters, so the response is not matched.
In addition fourth parameter is not used by parsing code.
|
|
We register translations for QMI core and QMI protocol errors. These
translations are a best-effort, and they are not meant to be
exhaustive.
The original error description is included in the translated GError,
so that the details of the issue are not lost.
|
|
We register translations for MBIM core, MBIM protocol and MBIM status
errors. These translations are a best-effort, and they are not meant
to be exhaustive.
The original error description is included in the translated GError,
so that the details of the issue are not lost.
|
|
The ModemManager API should not expose or return error types out of
the error domains it supports.
Default to a generic core error "Failed", while keeping the original
error description.
|
|
This allows us to skip needing to include the non-existent
build_string_from_mask() or get_string() counterparts in the
documentation index.
|
|
==174467== Invalid read of size 1
==174467== at 0x10B80C: read_bits (mm-sms-part-cdma.c:255)
==174467== by 0x10B886: read_bits (mm-sms-part-cdma.c:260)
==174467== by 0x10DC2F: read_bearer_data_user_data (mm-sms-part-cdma.c:882)
==174467== by 0x10DC2F: read_bearer_data (mm-sms-part-cdma.c:1000)
==174467== by 0x10DC2F: mm_sms_part_cdma_new_from_binary_pdu (mm-sms-part-cdma.c:1180)
==174467== by 0x10DF24: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:331)
==174467== by 0x10A91D: common_test_valid_part_from_hexpdu (test-sms-part-cdma.c:114)
==174467== by 0x10B0AC: common_test_valid_part_from_pdu (test-sms-part-cdma.c:126)
==174467== by 0x10B0AC: test_invalid_ascii_user_data (test-sms-part-cdma.c:412)
==174467== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== Address 0x51a6457 is 0 bytes after a block of size 7 alloc'd
==174467== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==174467== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==174467== by 0x10DF06: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:325)
==174467== by 0x10A91D: common_test_valid_part_from_hexpdu (test-sms-part-cdma.c:114)
==174467== by 0x10B0AC: common_test_valid_part_from_pdu (test-sms-part-cdma.c:126)
==174467== by 0x10B0AC: test_invalid_ascii_user_data (test-sms-part-cdma.c:412)
==174467== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
|
|
Same fix also applied to latin encoded text as it also makes sense there.
==158856== Invalid read of size 1
==158856== at 0x10B814: read_bits (mm-sms-part-cdma.c:257)
==158856== by 0x10DB07: read_bearer_data_user_data (mm-sms-part-cdma.c:878)
==158856== by 0x10DB07: read_bearer_data (mm-sms-part-cdma.c:990)
==158856== by 0x10DB07: mm_sms_part_cdma_new_from_binary_pdu (mm-sms-part-cdma.c:1170)
==158856== by 0x10DE54: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:333)
==158856== by 0x10A916: common_test_invalid_part_from_hexpdu (test-sms-part-cdma.c:90)
==158856== by 0x10A916: common_test_invalid_part_from_pdu (test-sms-part-cdma.c:104)
==158856== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02BBC: g_test_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x10A509: main (test-sms-part-cdma.c:595)
==158856== Address 0x51a627b is 0 bytes after a block of size 11 alloc'd
==158856== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==158856== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==158856== by 0x10DE36: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:327)
==158856== by 0x10A916: common_test_invalid_part_from_hexpdu (test-sms-part-cdma.c:90)
==158856== by 0x10A916: common_test_invalid_part_from_pdu (test-sms-part-cdma.c:104)
==158856== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02BBC: g_test_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856==
|
|
GLib-CRITICAL **: 21:21:51.419: g_convert: assertion 'str != NULL' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7db3e82 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff7db3e82 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff7db40ef in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7d8a5da in g_convert () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555555592cf in read_bearer_data_user_data (log_object=0x0, subparameter=<optimized out>, sms_part=0x555555578000)
at ../src/mm-sms-part-cdma.c:929
#4 read_bearer_data (log_object=0x0, parameter=<optimized out>, sms_part=0x555555578000) at ../src/mm-sms-part-cdma.c:982
#5 mm_sms_part_cdma_new_from_binary_pdu
|
|
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] submit type PDU detected
[debug] message reference: 1
[debug] address size: 1 digits (1 bytes)
[debug] number parsed: 00
[debug] validity available, format relative
[debug] PID: 0
[debug] user data encoding is GSM7
[debug] user data length: 0 elements
[debug] user data length: 0 bytes
==125780== Command: ./build/test/mmsmspdu --pdu=00F101010C0000000000 --verbose
==125780==
==125780== Invalid read of size 1
==125780== at 0x10B422: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:698)
==125780== by 0x10BF57: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==125780== by 0x10A44D: main (mmsmspdu.c:242)
==125780== Address 0x519988a is 0 bytes after a block of size 10 alloc'd
==125780== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==125780== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==125780== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==125780== by 0x10BF36: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==125780== by 0x10A44D: main (mmsmspdu.c:242)
|
|
==101461== Command: ./build/test/mmsmspdu --pdu=004100010100014B00002E --verbose
==101461==
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] submit type PDU detected
[debug] message reference: 0
[debug] address size: 1 digits (1 bytes)
[debug] number parsed: 00
[debug] PID: 1
[debug] user data encoding is GSM7
[debug] user data length: 0 elements
[debug] user data length: 0 bytes
[debug] decoding SMS text with 4294967294 elements
Based on a patch from Michal Mazur <mkm@semihalf.com>.
|
|
address
Before the actual number digits there is always a Type of Address byte
that we were not considering during the size check.
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] deliver type PDU detected
[debug] address size: 1 digits (1 bytes)
==90832== Command: ./build/test/mmsmspdu --pdu=001C011C --verbose
==90832==
==90832== Invalid read of size 1
==90832== at 0x10AC90: sms_semi_octets_to_bcd_string (mm-sms-part-3gpp.c:71)
==90832== by 0x10AC90: sms_decode_address (mm-sms-part-3gpp.c:157)
==90832== by 0x10B0C5: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:512)
==90832== by 0x10BF77: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==90832== by 0x10A44D: main (mmsmspdu.c:242)
==90832== Address 0x5199874 is 0 bytes after a block of size 4 alloc'd
==90832== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==90832== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==90832== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==90832== by 0x10BF56: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==90832== by 0x10A44D: main (mmsmspdu.c:242)
|
|
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] status report type PDU detected
[debug] message reference: 191
[debug] address size: 0 digits (0 bytes)
==78906== Command: ./build/test/mmsmspdu --pdu=000ABF00 --verbose
==78906==
==78906== Invalid read of size 1
==78906== at 0x10AA80: sms_decode_address (mm-sms-part-3gpp.c:132)
==78906== by 0x10AF7C: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:507)
==78906== by 0x10BE17: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==78906== by 0x10A44D: main (mmsmspdu.c:202)
==78906== Address 0x5199874 is 0 bytes after a block of size 4 alloc'd
==78906== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==78906== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==78906== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==78906== by 0x10BDF6: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==78906== by 0x10A44D: main (mmsmspdu.c:202)
|
|
|
|
|
|
Requires the response parser methods in libqmi.
|
|
|
|
character
|
|
|
|
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.
|
|
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
|
|
The rights each contributor has are the ones stated by the GPL/LGPL,
not more and not less.
|
|
Including 5GNR network reporting (act=12)
https://forum.sierrawireless.com/t/5g-network-scan-with-the-em9191-operation-not-allowed/26374/9
|
|
The numeric fields in the +COPS=? response were relying on a very weak
parsing logic, assuming that they were single-digit numeric values and
not using the common string to integer conversion utilities.
This commit improves the conversion from the 3GPP/ETSI defined network
availability and access technology values to the MM defined ones,
providing enum-based matches even if the numeric values are the same.
The commit also fixes the parsing of access technology values > 10,
required to report 5G related values.
|
|
Do not build the mask of "all" modes based only on the supported radio
interfaces, also filter out those modes that would not be available
based on the current capabilities enabled.
|
|
In GSM/UMTS+CDMA/EVDO multimode devices, the 4G and 5G mode switching
operations are exclusively limited to the capability selection that
has LTE+5GNR exclusively.
We cannot allow switching to 4G-only, 5G-only or 4G+5G if the current
capabilities have GSM/UMTS or CDMA/EVDO.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/503
|
|
|
|
Including tests for 5G-only and non-multimode 5G+4G and 5G+4G+3G devices.
|
|
|
|
The helper method for which we have unit tests available refers
exclusively to the current capabilities loading, so rename it to
clarify that.
|
|
|
|
Change due to update in current capabilities loading logic.
|
|
The input pattern given to the string_match() method is not a regex
pattern and we cannot use it as that, because all the special
characters (e.g. '.') would not be treated correctly.
Also, the prefix matching with the wildcard at the end of the string
needs to be converted to a proper regex wildcard, i.e. '.*'.
This logic also adds support for suffix matching, with a wildcard at
the beginning of the string, e.g. as the ones used for the wwan kernel
device name matching rules (i.e. '*MBIM').
Unit tests are added to cover all cases, most of these tests were
failing without the fixes implemented here.
|
|
|
|
|
|
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Includes updates by Aleksander Morgado to fix coding style issues.
|
|
Calls in a CLCC response in data-only or fax-only mode
do not count as actuall calls.
|
|
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
|
|
|
|
Use mm_obj_warn() instead.
|
|
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
|
|
First, simplify the logic that attempts to find the correct error code
associated to an error text string. This logic is very flaky, as it
relies on knowing what the modems report as text string for the
different error codes, and obviously that is not always the same.
Instead of supporting all error codes in this logic, we now limit them
to a small subset with common error codes and hopefully common error
strings.
Second, in order to quickly get the error description string for a
given error code, we rework the array of supported errors so that
the index of the array is the error code itself. For mobile equipment
errors the logic is straightforward, as they're always in the [0,255]
range, but for the message errors we create an array where the index
of the array is equal to the code plus 300 as they're always in the
[300,500] range. By doing this, we avoid having an array with 300 NULL
items before the actual values we want to support.
|
|
MNC digit count information is lost on conversion to integers. Make it
possible for the caller to get this information through a separate
boolean.
|
|
The new helpers allow converting a PDP context list returned from the
+CGDCONT? parser to a list of 3GPP profile objects.
The new mm_3gpp_profile_list_find_best() method is equivalent to the
mm_3gpp_select_best_cid() one, but using profile objects as
input/output instead of specific settings.
The unit tests that were testing mm_3gpp_select_best_cid() are also
converted to use mm_3gpp_profile_list_find_best().
|
|
Instead of blindly assuming that we can take whatever string given as
valid UTF-8, we'll always attempt to convert from the current modem
charset into UTF-8. Before we were doing this for hex-encoded UCS2,
but not for example for GSM-7.
And due to the now applied GSM-7 conversion, the mf627a/mf627b +COPS
parsing unit tests are updated accordingly, because when converting
from an input string that contains byte 0x40 ('@' in UTF-8) as if it
were GSM-7, the 0x40 is taken as character '¡', encoded as 0xc2,0xa1
in UTF-8).
|
|
|
|
Use the generic mm_modem_charset_bytearray_to_utf8() instead.
|
|
Use the generic mm_modem_charset_bytearray_from_utf8() instead.
|
|
If the conversion is not fully compatible, the user of the method
needs to request transliteration enabled explicitly in order to avoid
returning errors in this method.
|
|
Until now, this method would automatically apply transliteration;
i.e. replacing characters with '?' when no direct translation was
available.
We can attempt to do that transliteration on strings that are not
critical, e.g. the operator name reported by the network. But we
should not do that on other types of strings, e.g. on SMS contents
that may really have additional purposes than just being
human-readable.
This commit makes the transliteration option to be explicitly
requested by the caller.
|
|
|