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.
In mm_telit_model_from_revision there is nothing that prevents to use
the input revision string if it is NULL, which currently happens if
the modem is pure MBIM (i.e. LE910-V2 pid:0x0032).
Fix the above error returning a default safe value and not using the
NULL variable.
In some cases the "base" software package string does not have the
currently expected format of \d{2}.\d{2}.\d{3}. Specifically the last
triplet of characters might not be digits. For example a valid version
string might be 25.20.-04, which the current regex is unable to parse.
This change replace the previous regex with one less restrictive,
checking only the first part of the version's format.
Some modems, like LE910C1-EUX, express the LTE part of #BND output in
HEX format, but currently the MM parser for such case is limited to
modems that have "ext_4g_bands". This commits use the new MMTelitModel
info to decide how to parse #BND command output.
Fixes#487
Telit revision string can be used to identify the specific model, which
in turn is useful to specialize the behavior of the plugin.
This change adds revision parsing to detect some telit modems. Initially
it adds the ones that have different behaviors in #BND output parsing
for example.
Currently, firmware revision string is obtained via AT+CGMR or AT+GMR
commands from the default mm-broadband-modem. For a class of Telit
modems however this command does not return the actual Telit Software
Package version, but the "Modem FW Version", which is only a component
of the whole firmware. For this class of modems, the correct string is
obtained with "AT#SWPKGV" command.
This change overrides load_revision* functions to add the ability to
parse "AT#SWPKGV" command for the modems that support it, and falls back
to the same logic that was implemented in mm-broadband-modem otherwise.
Telit modems that require hexadecimal number when specifying 4G bands
also reply to #BND=? command with a 4th parameter <LTE_band_ext>
(e.g. LM940, LM960, LN920, FN980).
On the other hand, modems that require decimal number when specifying 4G
bands only return 3 parameters to the same command.
It is then possible replace the detection of ext_4g_bands via UDEV tags
with an inspection of BND=? reply.
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
telit/mm-modem-helpers-telit.c: In function 'mm_telit_build_bnd_request':
telit/mm-modem-helpers-telit.c:256:55: error: cast increases required alignment of target type [-Werror=cast-align]
bands_str = mm_common_build_bands_string ((const MMModemBand *)(bands_array->data), bands_array->len);
^
telit/mm-modem-helpers-telit.c:275:55: error: cast increases required alignment of target type [-Werror=cast-align]
bands_str = mm_common_build_bands_string ((const MMModemBand *)(bands_array->data), bands_array->len);
^
Since this plugin uses a bitmask to represent bands, we have
to be wary of shifting outside the precision of the bitmask
storage type. In this case, it was possible to generate 1 << 31
in a signed integer type as an intermediate step of B3G_FLAG,
which is undefined behavior (and usually results in INT_MIN,
breaking comparisons with the value).
Bug was reported to the chromium tracker at crbug.com/1019301
Original patch updated by Aleksander Morgado to leave
MM_MODEM_BAND_TELIT_3G_LAST as MM_MODEM_BAND_UTRAN_19, as that is the
highest 3G band supported by the current implementation. Worth noting
that this was not a real bug as the maximum flag we would have been
setting was (1 << 19) anyway.
And added support for several new things, including:
* Setting "any" band now attempts to set all supported bands.
* Added new 2G band value '5' (egsm+dcs+pcs+g850).
* Setup support for two different 3G band combinations, a default one
plus an alternate one applicable to the LM940/960 models only. The
alternate combination is selected via udev tags.
During the refactor, the following Telit-specific helpers were also
removed and exchanged with more generic counterparts.
* mm_telit_bands_contains() -> mm_common_bands_garray_lookup()
* mm_telit_get_band_flags_from_string() -> mm_parse_uint_list()
Updated to use the non-deprecated MMModemBand values.
Also, use explicit enums for 2G/3G bands when building internal flags,
as relying on UTRAN band 7 (MM_MODEM_BAND_U2600) being greater than
UTRAN bands 8 and 9 is a MM implementation issue.
Given that the MMTelitQssStatus enums are mapped directly to the
values read from the #QSS response, we need to make sure that we never
return a value for which we don't have an enum defined.
Also, use set_error() instead of the propagate_error() + error_new()
combo.
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with current implementation, even receiving "#QSS: 3" will
trigger the "SIM swap" logic. The same issue might occur in other use cases
too, i.e. with SIM locked or when the message is received from both USB
ports.
This patch makes SIM swap implementation stateful, and it considers as an
actual SIM swap, only transitions from #QSS: 0 to #QSS: 1/2/3 and vice
versa.
- Refactored mm_telit_parse_csim_response in order to correctly
recognize the following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
- Updated correspondent tests.
- Finally, some minor changes in other files for better error logging
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100374
In place of two slightly different regexes for 2g/3g and 2g/3g/4g modems
we now use only one regex with conditional patterns for both supported
and current Bands detection.
Adding also minor fix in test code
GE910 is a 2g only modem and when queried for bands it returns
only a 2g set of bands:
--> 'AT#BND=?<CR>'
<-- '<CR><LF>#BND: (0-3)<CR><LF><CR><LF>OK<CR><LF>'
Current regex fails, since it considers the 3g bands block mandatory.
A similar problem happens for current bands.
This patch modifies the regular expressions for properly
supporting GE910 and updates tests.
Aleksander Morgado
Carlo Lobrano
Carlo Lobrano
Amol Lad
Aleksander Morgado
Eric Caruso
Daniele Palmas
Ville Skyttä
Colin Helliwell
Ben Chan