On a failed QMI modem connection, we won't return the generic
"CallFailed" error, we'll try to convert the 3GPP verbose call end
reason to a MMMobileEquipmentError.
And if we cannot find a mapping, or if the reported error is not a
3GPP verbose call end reason, we'll return a Unknown
MMMobileEquipmentError with a string message providing detailed error
information.
Instead of having a switch with a lot of cases, provide a one to one
mapping for the MbimNwError and MMMobileEquipmentError codes in an
array, and make use of the mm_mobile_equipment_error_for_code() helper
to build the actual GError.
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
First, simplify the logic that attempts to find the correct error code
associated to an error text string. This logic is very flaky, as it
relies on knowing what the modems report as text string for the
different error codes, and obviously that is not always the same.
Instead of supporting all error codes in this logic, we now limit them
to a small subset with common error codes and hopefully common error
strings.
Second, in order to quickly get the error description string for a
given error code, we rework the array of supported errors so that
the index of the array is the error code itself. For mobile equipment
errors the logic is straightforward, as they're always in the [0,255]
range, but for the message errors we create an array where the index
of the array is equal to the code plus 300 as they're always in the
[300,500] range. By doing this, we avoid having an array with 300 NULL
items before the actual values we want to support.
Use the new generic FCC unlock step instead of implementing it within
the operating mode setup logic.
The operation is implemented in the MMSharedQmi interface as it will
also be used by the MBIM modem object.
There are devices that come locked before they can be put online.
Until now we had a specific implementation for this in the generic QMI
modem, but we should have it in a more generic way for any kind of
modem.
MMLocation3gpp provides MCC/MNC information as integers, so it can not
make distinction between operator codes such as XXX01 and XXX001.
This commit deprecates mm_location_3gpp_get_mobile_network_code() and
implements a new function mm_location_3gpp_get_operator_code() which
provides the MCC+MNC in string format.
The mm_location_3gpp_get_mobile_country_code() is still available as
returning the MCC as an integer does not have ambiguity issues.
The modem may be camping in a forbidden network just for emergency
services, and we'll be able to have a MCCMNC reported in that case,
but this does not mean the modem is registered.
So, don't consider that a valid registration flag during the new
network registration request.
We'll setup the properties only if QRTR support is being built,
otherwise we fully skip all property related setup.
(ModemManager:480463): GLib-GObject-CRITICAL **: 22:48:14.264: g_object_class_install_properties: assertion 'n_pspecs > 1' failed
Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff76e3295 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff76e3295 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff76e4579 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff76e4743 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555556af70c in mm_port_qmi_class_init (klass=0x5555557fae20) at mm-port-qmi.c:2619
#4 0x00005555556a94c3 in mm_port_qmi_class_intern_init (klass=0x5555557fae20) at mm-port-qmi.c:34
#5 0x00007ffff77ed1d1 in g_type_class_ref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007ffff77d05e1 in g_object_new_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff77d06cd in g_object_new () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00005555556af25a in mm_port_qmi_new (name=0x5555557e54e0 "cdc-wdm0", subsys=MM_PORT_SUBSYS_USBMISC) at mm-port-qmi.c:2481
#9 0x000055555563c8d7 in wdm_probe_qmi (self=0x5555557de1b0) at mm-port-probe.c:517
#10 0x000055555563cc70 in wdm_probe (self=0x5555557de1b0) at mm-port-probe.c:623
#11 0x00007ffff76dd04e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff76dd400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff76dd6f3 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00005555555b1ae4 in main (argc=1, argv=0x7fffffffe558) at main.c:213
Print a debug message when the user provides initial eps bearer settings
that match the ones being used. This will save time to whomever is
experimenting with initial eps bearer settings.
For now WWAN subsystem support has only been validated for PCI/MHI
based devices and extra patches for USB based devices (qmi_wwan,
cdc-mbim...) may be required, so do not consider WWAN ports being
on USB bus.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
move the modem_load_model() async method from mm-broadband-modem-qmi.c
to mm-shared-qmi.c, and then make use of the method from both the QMI
and MBIM implementations.
When updating the registration state, in the case where LTE is not ready,
ensure we reset the EPS registration state rather than leaving its old
value.
Else when the consolidated registration is built, it can wrongly think
we are registered, e.g. the following case was happening:
[modem0] consolidated registration state: cs 'home', ps 'home', eps 'home', 5gs 'unknown' --> 'home'
a bit later
[modem0] consolidated registration state: cs 'unknown', ps 'unknown', eps 'home', 5gs 'unknown' --> 'home'
then it wrongly tries immediatly to connect
and fails due to 'no-service'
On Qualcomm SC7180, running the following sequence would often reproduce
it:
<stop higher level network manager>
mmcli -m 0 -d
mmcli -m 0 --set-power-state-low
sleep 10
mmcli -m 0 -e
mmcli -m 0 --simple-connect="apn=broadband"
We should not try to match the 'profile-id', as that setting is not
available in the input bearer settings provided by the user.
And we should not try to match the 'apn-type', as not all
implementations support it and it's not really necessary for this
purpose anyway.
The operation required to load/update the initial EPS bearer settings
are completely the same as for profile management, because at the end
the settings are bound to a specific profile id.
If we find that none of the requested auth settings are supported, we
should fail and return an error.
Also, make sure we set the CHAP fallback default only if either user
or password are given.
Unlike other implementations, with MBIM we cannot tell the modem to
connect a given profile by its profile number, which is a bit strange,
but it looks like there is no way to do that. So, if the user requests
to connect a given profile, what we do is load the profile settings by
querying the modem, and use those settings in the connect request.
We use the "Provisioned Contexts" message support to add and edit
profiles.
We also use the same message, with context-type set to "none" to
attempt deleting it, although that doesn't seem to be fully supported
by all modems. E.g. the EM7345 (FIH7160_V1.1_MODEM_01.1349.12) will
still report contexts 'deleted' in this way, with the context-type set
to "none".º
There is no longer need to perform all the CID selection logic in the
broadband bearer connection procedure, we can rely on the new profile
management operations to do the same thing.
We can do this because we're sure that all the MMBroadbandModem
objects implement the MMModem3gppProfileManager interface.
Additionally, given that we now provide the profile ID value as part
of the MMBearerConnectResult, we no longer need a custom
mm_broadband_bearer_get_3gpp_cid() as we can use the generic
mm_base_bearer_get_profile_id() for the same purpose.
Using AT+CGDCONT for profile settings management (querying, updating,
reseting), AT+CGDEL for profile deletion, and AT+CGACT for activation
status management (check, deactivate).
This interface will provide support for the profile management
operations in different modem types.
This initial commit introduces support for the interface and provides
handlers for the methods that may be called in the interface.
The new helpers allow converting a PDP context list returned from the
+CGDCONT? parser to a list of 3GPP profile objects.
The new mm_3gpp_profile_list_find_best() method is equivalent to the
mm_3gpp_select_best_cid() one, but using profile objects as
input/output instead of specific settings.
The unit tests that were testing mm_3gpp_select_best_cid() are also
converted to use mm_3gpp_profile_list_find_best().
Some of the operations performed by the profile management interface
will require checking whether the operation is attempted on a profile
for which there is a known connected bearer object.
We introduce a new method to lookup a bearer in the bearer list by its
connected profile id.
Implementations that support profile management will provide the
connected profile id value in the MMBearerConnectResult returned to
the base bearer object during the connection attempt.
We define a new 'profile-id' setting in the bearer properties that
users will use to specify which connection profile of the ones
available in the device should be connected.
When the 'profile-id' is given, the associated bearer object will be
bound to the 'profile-id', and the user is able to provide additional
settings to apply on top (e.g. if the profile storage doesn't allow
some of the settings we support, like 'apn-type', or if the setting is
completely unrelated to profiles, like 'multiplex').
After introducing the 'profile-id' as a valid setting in the bearer
properties, we also reimplement the properties object internals to
make use a 3GPP profile for the subset of common settings between both
objects.
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
Aleksander Morgado
Teijo Kinnunen
Andrew Lassalle
Loic Poulain
Freedom Liu
goapunk
Eric Caruso
Michal Mazur
Vincent Palatin