Fix the test for invalid characters, because now I allow hex chars in
the account number.
And add new tests with real China Mobile ICCIDs that contain hex chars
in the account number.
There are operators (e.g. the Chinese CMCC operator) that abuse the
fact that 4 bits are used to store the BCD encoded numbers, and also
use the [A-F] range as valid characters for the ICCID in the operator
specific account number part. Haven't seen any documentation where
this format with [A-F] characters is explicitly allowed, but I have
seen multiple real cases where it happens. E.g.:
898602F9091830030220
898602C0123456789012
This patch also removes the 'last F' validation, used when reading
19-digit ICCIDs with +CRSM, as it no longer applies.
The mm_3gpp_parse_iccid() method does validation of the ICCID string
and was originally implemented to handle +CRSM reported values. The
implementation was looking for 20-digit strings, even for 19-digit
ICCIDs (those finished with a trailing 'F').
We now extend the logic to also validate ICCID strings reported as
19-digit values directly, and when that happens we won't allow
swapping of the digits (a +CRSM specific requirement) or trailing 'F'
characters (as that is only required when reporting 19-digit ICCIDs
with 20-digit strings).
This change allows us to e.g. use the u-blox specific AT+CCID command
and validate the returned ICCID with the same helper method, which
currently fails:
(ttyACM2): --> 'AT+CCID<CR>'
(ttyACM2): <-- '<CR><LF>+CCID: 8934077700015848638<CR><LF><CR><LF>OK<CR><LF>'
couldn't load SIM identifier: 'Invalid ICCID response size (was 19, expected 20)'
We're already configuring the flow control we expect when running
mm_port_serial_reopen(), which will keep the udev-selected flow
control or will otherwise reset to no flow control when the TTY is in
command mode.
If a subclass implements a custom setup_flow_control() logic, e.g. to
select a very specific setting explicitly, let it also configure the
flow control settings modem-wide via the modem object property, so
that bearer objects can later on use the same settings when preparing
for a new connection.
Try to simplify a bit the logic that selects the flow control to be
used during connectivity:
* We detect early if the requested flow control (via udev tags) is
actually supported by the modem (as eported by AT+IFC=?), and if it
isn't, we error out directly.
* We try to set in a single place the AT commands to be used to setup
the flow control, once we have decided which one we're going to
use.
* Use the string builder helpers to log the flow control values.
MMFlowControl is a flags enumeration, so change the property type to
match that, or we'll end up with nasty criticals during runtime.
(ModemManager:30758): GLib-GObject-CRITICAL **: 10:54:26.435: g_param_spec_enum: assertion 'G_TYPE_IS_ENUM (enum_type)' failed
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff71f2a96 in ?? () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff71f2a96 in () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff71f3def in g_logv () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff71f3fe0 in g_log () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff72d90ac in g_param_spec_enum () at /usr/lib/libgobject-2.0.so.0
#4 0x000055555564caf2 in mm_port_serial_class_init (klass=0x5555557607c0) at mm-port-serial.c:2101
#5 0x000055555564759a in mm_port_serial_class_intern_init (klass=0x5555557607c0) at mm-port-serial.c:49
#6 0x00007ffff72ea9b4 in g_type_class_ref () at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff72eab5a in g_type_class_ref () at /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff72d0f53 in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff72d103a in g_object_new () at /usr/lib/libgobject-2.0.so.0
#10 0x000055555564e187 in mm_port_serial_at_new (name=0x55555576e280 "ttyUSB4", subsys=MM_PORT_SUBSYS_TTY) at mm-port-serial-at.c:533
#11 0x0000555555602512 in serial_open_at (self=0x555555715390) at mm-port-probe.c:1285
#12 0x00007ffff71ecb49 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#13 0x00007ffff71ecf59 in () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff71ed272 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x00005555555957e0 in main (argc=3, argv=0x7fffffffe458) at
main.c:181
Also, rename the property to match the naming convention of other
properties in the same object.
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.
