Devices will expect SUPL server given as either IP:PORT or FQDN:PORT,
so just avoid saying we require a 'URL' because it's not true.
We will use a new helper method to parse and validate user-provided
SUPL server address.
On CDMA-only connections we won't have a CID defined, so instead of
getting in a loop of warnings reporting "cid not defined", early error
out with an UNSUPPORTED error so that the connection check isn't tried
any more.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/83
In order to avoid having the result values in 2 places (context and
result) when the GTask is completed, we will steal the pointer from
the context before it's set as result of the GTask.
This patch fixes the following compiler warning:
xmm/mm-modem-helpers-xmm.c:388:38: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
g_regex_match_full (r, response, strlen (response), 0, 0, &match_info, &inner_error);
^
This patch fixes the following compiler warning:
mm-shared-qmi.c:447:9: error: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Werror,-Wimplicit-function-declaration]
memset (buf, 0, sizeof (buf));
^
Implement a new interface to keep the code shared between the QMI and
non-QMI modem implementations.
While doing that, also fix the parent interface pointer handling, so
that it isn't a static pointer applicable to all modems, and make it a
per-modem specific pointer. Without this fix, ModemManager would crash
if e.g. running with both a QMI and non-QMI Cinterion modem at the
same time.
The new shared Cinterion logic will be in charge of managing all GPS
sources not already managed by the parent interface. E.g. if the
parent implementation already supports QMI-based GPS location (using
the LOC service for example) prefer that to the custom AT-based
logic.
Most of all the other APIs we have are expecting binary data (e.g.
UCS-2 encoded strings) in ASCII hex format, because they were going
to be used in text AT commands. For binary protocols allowing binary
data, we need use a more generic API that provides an explicit data
size.
Configuring reports every 5s may lead to GPGGA traces reported like this:
$GPGGA,211645.00,,,,,0,,,,,,,,*4D
$GPGGA,211646.00,4030.003988,N,00330.761876,W,1,07,1.0,691.6,M,53.0,M,,*74
$GPGGA,211650.00,,,,,0,,,,,,,,*49
$GPGGA,211651.00,4030.005405,N,00330.763540,W,1,07,1.0,688.9,M,53.0,M,,*71
$GPGGA,211655.00,,,,,0,,,,,,,,*4C
$GPGGA,211656.00,4030.008074,N,00330.765338,W,1,07,0.9,679.9,M,53.0,M,,*70
$GPGGA,211700.00,,,,,0,,,,,,,,*4D
$GPGGA,211701.00,4030.009258,N,00330.765510,W,1,07,1.0,678.3,M,53.0,M,,*71
$GPGGA,211705.00,,,,,0,,,,,,,,*48
Which is totally undesirable, as the GPS location would be flapping
between set and unset.
Use the default of 1s explicitly, which behaves properly.
For non-Qualcomm MBIM devices, report a generic "Unsupported" error if
we try to do an operation that would otherwise be only available with
QMI-over-MBIM.