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.
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
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.
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.
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.
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).
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.
All BCD-encoded strings used by MM currently have the low nybble
of each byte come before the high nybble, but some strings (such
as the EID string returned by QMI Get Slot Status) are meant to
be read in order with the high nybble before the low one. As such,
extend mm_bcd_to_string to decode both.
Despite 3GPP TS 23.038 specifies that Unicode SMS messages are
encoded in UCS-2, UTF-16 encoding is commonly used instead on many
modern platforms to allow encoding code points that fall outside the
Basic Multilingual Plane (BMP), such as Emoji.
Update the logic to always use UTF-16 instead of UCS-2 when creating
or parsing PDUs (even if we always report as sending or receiving
UCS-2). For all purposes, UCS-2 is considered a subset of UTF-16
(assuming that code points out of the [U+0000,U+D7FF] and
[U+E000,U+FFFF] ranges are not applicable in UCS-2).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/250
test-qcdm-serial-port.c: In function 'wait_for_child':
test-qcdm-serial-port.c:57:52: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (d->child && (now.tv_sec - start.tv_sec > timeout)) {
^