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.
g_date_time_new, and g_date_time_new_utc return NULL if inputs are out
of range, and currently mm_new_iso8601_time passes the GDateTime created
by those two functions to date_time_format_iso8601 without checking for
NULL values, causing a g_date_time_format_iso8601 crash if PDU data is
corrupted with wrong date.
To prevent this, mm_new_iso8601_time now can return NULL and set a new
GError if GDateTime created by g_date_time_new is NULL.
Fixes#546
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.
+CGDCONT? may list profiles with IDs that are illegal to write, i.e.
+CGDCONT=? returns a minimum ID larger than some of the existing
profiles. E.g. for Fibocom L610-EU, +CGDCONT=? returns
+CGDCONT: (1-7),"IP",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV6",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV4V6",,,(0-3),(0-4)
+CGDCONT: (1-7),"PPP",,,(0-3),(0-4)
+CGDCONT: (1-7),"Non-IP",,,(0-3),(0-4)
while the default EPS bearer is established at profile 0:
+CGDCONT: 0,"IP","xxx","xxx.xxx.xxx.xxx",0,0
[...]
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
We use capability switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE/5GNR or not) to add or remove the GSM/UMTS and CDMA/EVDO
capabilities.
Based on the same logic, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE+5GNR device:
"GSM/UMTS+CDMA/EVDO+LTE+5GNR", "GSM/UMTS+LTE+5GNR", "CDMA/EVDO+LTE+5GNR" and "LTE+5GNR"
Similarly, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE device:
"GSM/UMTS+CDMA/EVDO+LTE", "GSM/UMTS+LTE", "CDMA/EVDO+LTE" and "LTE"
And, we will allow 3 combinations for GSM/UMTS+CDMA/EVDO device:
"GSM/UMTS+CDMA/EVDO", "GSM/UMTS" and "CDMA/EVDO"
Also, supported combination modes should be based on current capabilities and not entirely
upon supported radio interfaces.
1) If current capability has "gsm-umts" or "cdma-evdo" or both, do not
support 4G only, 5G only, or 4G+5G combination modes
2) If current capability neither has "gsm-umts" nor "cdma-evdo", only support
combination modes involving 4G and 5G.
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
There is no longer need to perform all the CID selection logic in the
broadband bearer connection procedure, we can rely on the new profile
management operations to do the same thing.
We can do this because we're sure that all the MMBroadbandModem
objects implement the MMModem3gppProfileManager interface.
Additionally, given that we now provide the profile ID value as part
of the MMBearerConnectResult, we no longer need a custom
mm_broadband_bearer_get_3gpp_cid() as we can use the generic
mm_base_bearer_get_profile_id() for the same purpose.
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().
There is no point in providing a configurable default IP family in the
bearer object, because we can always assume IPv4 as being the only
default expected.
Simplify the logic and also provide a new method to get the normalize
the IP family, using IPv4 as default always.
The ModemManager1.Sim.PreferredNetworks property contains the preferred
networks (and access technologies, if available) configured to the
SIM card.
This commit implements preferred networks reading with AT+CPOL.
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).
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.
So that we avoid errors when building on ARM due to increasing target
type alignment.
mm-modem-helpers.c: In function 'mm_3gpp_parse_cnum_exec_response':
mm-modem-helpers.c:3206:21: error: cast increases required alignment of target type [-Werror=cast-align]
return (array ? (GStrv) g_array_free (array, FALSE) : NULL);
^
This fixes the s8500 wave unit test, which was incorrectly parsing the
Act field reported as 'B' as "GSM" (strtol(B)=0)
Also, given that the generic parsing methods are able to parse numbers
from quoted strings, this change allows us to remove the Thuraya
specific CREG matching that just took into consideration quoted
strings. The Thuraya unit tests are also fixed up to provide proper
testing of the logic.
Aleksander Morgado
Angus Ainslie
Alexey Orishko
Carlo Lobrano
Aleksander Morgado
Sven Schwermer
Prakash Pabba
Frederic Martinsons
Som_SP
Dylan Van Assche
Teijo Kinnunen
Eric Caruso