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
huawei/mm-modem-helpers-huawei.c: In function ‘parse_mode_combination_string’:
huawei/mm-modem-helpers-huawei.c:991:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
991 | *preferred = MM_MODEM_MODE_NONE;
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
huawei/mm-modem-helpers-huawei.c:993:5: note: here
993 | default:
| ^~~~~~~
huawei/mm-modem-helpers-huawei.c: In function ‘mm_huawei_parse_prefmode_response’:
huawei/mm-modem-helpers-huawei.c:550:18: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘const unsigned int’} [-Werror=sign-compare]
550 | if (mode == combination->prefmode)
| ^~
USB sticks only support voice if ^CVOICE returns 0. And to enable audio
streaming on the "Application" port (whatever is returned by AT^DDSETEX=?)
we need to send AT^DDSETEX=<port> after starting the call. After that
the serial port will send and accept signed 16-bit 8000hz PCM audio, or
whatever format is returned by ^CVOICE?.
This patch is a rework of the original implementation by:
Dan Williams <dcbw@redhat.com>
On Huawei ME936, the hex numbers in the response to AT^DHCP contain the 0x prefix, e.g.
AT^DHCP?
^DHCP: 0xda7d0e0a,0xff000000,0xdb7d0e0a,0xdb7d0e0a,0x01261aac,0x00000000,100000000,50000000
This patch updates mm_huawei_parse_dhcp_response() to handle the
optional 0x prefix.
<debug> (ttyUSB2): --> 'AT^SYSCFG?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>^SYSCFG:14,2,400380,1,2<CR><LF><CR><LF>OK<CR><LF>'
<warn> couldn't load current allowed/preferred modes: 'No SYSCFG combination found matching the current one (14,2)'
14,2 means "WCDMA-only; acquire WCDMA then GSM" which is somewhat
non-sensical. The supported modes parsing doesn't generate this
combination because it doesn't really make sense, so current mode
matching failed. Just fix up the non-sensical acquisition order
to 0 (automatic).
Implement the detailed signal info interface for some Huawei 3GPP modems
including those based on HiSilicon chipsets like the E3276. Known not to
work on many Qualcomm-based Huawei modems like E392, E397, and E367 as
they don't support the ^HCSQ command, but they do support QMI and so
have access to the extended signal interface via QMI.
For non-QMI/non-MBIM Huawei devices that use HiSense chipsets,
the recommended way to create the connection is to use NDISDUP
and either DHCP on the net interface, or the ^DHCP command.
There are some reports of devices that connect successfully, but
don't respond to DHCP requests on the interface. Try to get
IP addressing info from the device via ^DHCP and fall back to
telling clients to use actual DHCP if that fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1254886
Third revision of Huawei nwtime support. Takes on feedback from the
mailing list including helpers, some basic tests and use of the ^NTCT
command to determine network time support (^NWTIME). Expanded test cases,
more use of g_assert and more logical helper return values/errors.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
This patch fixes mm_huawei_parse_prefmode_test to always report an error when
returning NULL, which avoid a potential crash when the caller tries to access
the error.
The original sysinfoex_parse() in MMBroadbandModemHuawei does not handle
unquoted <sysmode_name> and <submode_name> fields in ^SYSINFOEX responses,
which are sen on some Huawei modems (e.g. E303). This patch moves the
^SYSINFOEX parsing code to mm-modem-helpers-huawei.c, fixes the regex for
handling unquoted strings in ^SYSINFOEX responses, and adds unit tests.
The original sysinfo_parse() in MMBroadbandModemHuawei incorrectly sets
'out_sys_submode_valid' to TRUE even when <sys_submode> is not present
in a ^SYSINFO response. This patch moves the code to
mm-modem-helpers-huawei.c, fixes the regex for parsing ^SYSINFO
responses, and adds unit tests.
This patch changes MMBroadbandModemHuawei to use ^NDISSTAT unsolicited
messages to handle network-initiated disconnection. As a ^NDISSTAT
unsolicited message is similar to a ^NDISSTATQRY response, the patch
extends the ^NDISSTATQRY parser code to handle both ^NDISSTAT and
^NDISSTATQRY responses.
Newer firmware for Huawei devices will not split the IPv4 and IPv6 info in
different lines for the ^NDISSTATQRY reply; instead they will be included in the
same line. E.g. instead of
^NDISSTATQRY: 1,,,IPV4
^NDISSTATQRY: 0,33,,IPV6
OK
We may have:
^NDISSTATQRY:0,,,"IPV4",0,33,,"IPV6"
Also note the optional spaces after the ':', and that in the new version the
strings are enclosed in double quotes.
https://bugzilla.gnome.org/show_bug.cgi?id=705339