This prevents errors due to nasty typos in the strings.
We define all symbols in a single header file that is NOT considered
part of the API, as there is no need for MM clients to know about
these tags code-wise. These tags are only meaningful when associated
to devices in udev.
Information of each tag is included in the general API documentation.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
Some plugins or implementations (e.g. notably MBIM) may report a
single storage as supported and no way to update the current default
storage. In this specific case, we will initialize the default storage
to that single one supported right away, regardless of whether
selecting others is implemented or not.
E.g. China Mobile (MCC 460, MNC 0).
$ mmcli -m toby --location-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
3GPP location | Mobile country code: '460'
| Mobile network code: '0'
| Location area code: '6188'
| Cell ID: '40955'
-------------------------
GPS NMEA traces | Not available
-------------------------
Raw GPS | Not available
-------------------------
CDMA BS | Not available
Remove the redundant declaration of which slipped into the code in commit
091bf4dbd8 ("api: support location assistance data").
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
The DW5821E module is managed in MBIM mode by default, and exposes a
NMEA capable tty in USB interface #4.
Enabling/disabling the NMEA output via the TTY is done with AT
commands, so this implementation requires also a valid AT port in the
system.
Given that the AT commands used to enable/disable this feature are
based on modifying non-volatile memory through AT^NV, this
implementation is very specific to the DW5821E. If we're able to do
the same on other Dell modules in the future, we'll just rename the
new object to a more generic one.
The implementation available in the shared QMI logic can be used
as-is, with one important note: if the QMI-based mode/capability
switching is used, we MUST also use QMI-based "3GPP network
registration" logic. This is needed because the MBIM command used to
select which 3GPP network to connect to allows specifying the mask of
access technologies desired, and that would overwrite whatever we had
previously set with QMI-based mode/capability switching commands.
Ported from the broadband modem QMI implementation, keeping the logic
in place. We will need this to integrate mode/capability switching in
MBIM devices, for nothing else really (as MBIM already supports this
operation).
This commit introduces several improvements and changes in the way
modes and capabilities are managed in QMI capable devices. It is
organized into a single commit, as all changes in all 6 operations
(load current capabilities, load supported capabilities, set current
capabilities, load supported modes, load current modes, set current
modes) are related one to the other (given that the same QMI commands
are used for both capabilities and mode management).
The primary change is related to which capabilities are reported as
supported for a given device. In the previous implementation we
allowed switching between every combination possible for GSM/UMTS+LTE,
CDMA/EVDO+LTE or GSM/UMTS+CDMA/EVDO+LTE devices. E.g. we would allow
"LTE only" and "GSM/UMTS only" capabilities for GSM/UMTS+LTE devices,
even if they would both be managed in exactly the same way. That setup
wasn't ideal, because it meant that switching to a "LTE only"
configuration would require a power cycle, as capability switching
requires a power cycle, even if no change was expected in the exposed
DBus interfaces (which is why we require the power cycle). So, instead
of allowing every possible capability combination, we use capability
switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE or not) to add or remove the
GSM/UMTS and CDMA/EVDO capabilities. E.g. for a GSM/UMTS+CDMA/EVDO+LTE
device we would allow 3 combinatios: "GSM/UMTS+LTE", "CDMA/EVDO+LTE"
and "GSM/UMTS+CDMA/EVDO+LTE".
The "GSM/UMTS+CDMA/EVDO+LTE" is a special case because for this one we
allow switching to "LTE only" capabilities while we forbid switching
to "4G only" mode. As the same commands are used for mode and
capability switching, if we didn't have "LTE only" and we allowed "4G
only" mode instead and rebooted the device, we would end up not being
able to know which other capabilities (GSM/UMTS or CDMA/EVDO or both)
were also enabled.
Now that we have capability switching confined to a very subset of
combinations, we can use the mode switching logic to e.g. allow "4G
only" configurations in all non multimode devices, as well as masks of
allowed modes with one being preferred, which we didn't allow before.
In the previous implementation all mode switching logic was disabled
for LTE capable QMI devices. In the new implementation, we use the
"Acquisition Order Preference" TLV in NAS Set System Selection
Preference to define the full list of mode preferences for all
supported modes.
We also no longer just assume that NAS Technology Preference is always
available and NAS System Selection Preference only after NAS >= 1.1.
This logic is flawed, instead we're going to probe for those features
once when loading current capabilities, and we then just implement the
capabilities/mode switching logic based on that.
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
