When using glib < 2.55.1 there was a bug in GLib triggering a huge
amount of memory leaks in the normal ModemManager runtime. This has
caused multiple issues in multiple setups, and so the best way to make
sure it no longer happens is to require 2.56.
The 2.56.0 glib version is also the one provided by Ubuntu 18.04 LTS,
and so we can now say that this LTS release is the last one we support
in newer MM releases. The previous Ubuntu 16.04 LTS is already out of
the standard 5-year support.
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".º
Using AT%IPDPCFG for authentication related profile settings
management (querying, updating), and relying on the parent
implementation for the remaining ones.
And using AT%IPDPACT for activation status management (deactivate),
while relying on the parent implementation for the activated check.
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.
To report which is the currently active profile with this bearer, if
known. If the modem doesn't support profiles, or if the bearer is
disconnected, -1 (MM_3GPP_PROFILE_ID_UNKNOWN) will be reported.
It is guaranteed that no two connected bearers will have the same
ProfileId property value.
This new interface allows modems to expose the list of available
connection profiles stored in the device and edit or delete them; as
long as the underlying device/protocol allows it.
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.
Define a new helper object which we're going to use to implement the
new profile management interface.
The 3GPP profile object provides the list of settings that modems may
be able to store in their profile list, e.g. "apn", "ip-type" and so
on. Not all modems will be able to support all the settings defined in
the profile object, and therefore, when looking for a specific 3GPP
profile object with a given set of settings, we must make sure we only
compare those settings that are supported by the modem.
The profile management implementation will be able to load during
runtime a set of "compare flags", specifying which settings should not
be checked during the comparison. E.g. a generic AT-based modem that
supports only "apn" and "ip-type" will be compared with the
NO_APN_TYPE and NO_AUTH flags; and an AT/Icera-based modem (which
supports auth settings) will use only NO_APN_TYPE.
The settings in the 3GPP profile should be considered a subset of the
bearer properties.
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.
0x0489 is the vendor ID of T77W968, 0x105b is the vendor ID of T99W175.
{0x105b, 0xe0b0},{0x105b, 0xe0b1} is T99W175 PCI device, used by Dell.
{0x105b, 0xe0ab} is T99W175 PCI device, used by Lenovo.
If the modem has an mbim port, create a MbimFoxconn object, regardless
of what the product ID is.
The firmware version format in the T99W175 was selected to have
firmware version + carrier config version + apps version.
TEST: test-stub...
/MM/stub/modem/interface: dbus-daemon[48020]: [session uid=0 pid=48020] Activating service name='org.freedesktop.ModemManager1' requested by ':1.0' (uid=0 pid=48005 comm="/builds/mobile-broadband/ModemManager/tools/tests/")
Traceback (most recent call last):
File "/builds/mobile-broadband/ModemManager/tools/test-modemmanager-service.py", line 7, in <module>
gi.require_version('ModemManager', '1.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace ModemManager not available
dbus-daemon[48020]: [session uid=0 pid=48020] Activated service 'org.freedesktop.ModemManager1' failed: Process org.freedesktop.ModemManager1 exited with status 1
The template image we're using already contains all the necessary
build deps to enable introspection and gtk-doc, so we need to
explicitly disable them where we don't need them, or otherwise they'll
be automatically enabled as the deps are found.
The "ready" methods for each step in the state machine must be ordered
from bottom to top, so that the readers can read the methods in that
order when following the logic.
In addition to differentiating between IPv4 and IPv6 clients, we also
need to explicitly allocate different clients in different bearer
objects when in multiplexing.
Connecting the second family of a dual stack connections fails with
'PolicyMismatch' when muxing is setup after family selection.
Switching the order of the family selection and muxing setup to
fix the problem. Looks like family selection must be the very last
WDS request before connecting the client.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Fix typo causing crash when WITH_QRTR is undefined:
[6596]: <debug> [1619029470.854688] [cdc-wdm0/probe] probing QMI...
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
(gdb) bt
#0 0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
#1 0x77a731db in validate_and_install_class_property () from /usr/lib/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC
Fixes: ec375bd959 ("port-qmi: add support for QRTR")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
SDX55 modem can take slighlty more than 25 seconds to start all
its services from cold boot/reset (including QMI services), causing
QMI port opening timeout error. This patch increases the qmi_device_open
timeout from 25 seconds to 45 seconds to prevent such issue.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
If multiplexing is not supported by the network driver, do not enable
it by default and fail in case it is required.
This is the case for mhi_net driver, that do no implement multi MBIM
session (only session 0 is supported).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
wwan is a new subsystem for WWAN devices, allowing to expose the
WWAN device and its ports in a generic way.
The sysfs hierarchy for such device is
/sys/class/wwanX
/sys/class/wwanX/wwanXpYP
Where X is the WWAN device index, Y the port index and P the
control protocol name (QMI, MBIM...). A control port is also
exposed as character device in /dev.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
