Since ModemManager 1.0 we were publishing symbols to identify all the
possible DBus error name prefixes, but these were never documented,
they were explicitly ignored in gtk-doc.
Let's provide proper documentation for them and make them first-class
API symbols.
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.
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.
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
The ModemManager-names.h header file is generated on git builds, and
shipped within the release tarball, so treat it as a maintainer
managed file that should only be removed on 'maintainer-clean'.
This allows us to avoid requiring xsltproc to build release tarballs.
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
When the MT detects an attempt to disconnect the last PDN or when the
network returns a response message with cause value #49, the "Last PDN
disconnection not allowed" error is returned.
The numeric error code was changed from 151 to 171 in 3GPP Rel-11, and
therefore there are devices out there that would conform to Rel-10 or
below and that would report +CME ERROR code 151 instead of 171. Given
that 151 isn't defined to a different meaning in the specs, let's
define it in the same way as 171.
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
So that we can avoid gtk-doc complaining about them:
2019-10-14 10:46:59,583:common.py:ParseEnumDeclaration:427:WARNING:Cannot parse enumeration member:
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_FIRST is missing in source code comment block.
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_LAST is missing in source code comment block.
This tag is completely redundant because users can whitelist the
platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS
tag, which is part of the explicit whitelist filter rule.
The udev tag that allows flagging devices that MAY be modems
(e.g. USB<->RS232 adapters) is only applicable to TTY devices, so
explicitly specify that in the tag name as well.
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
This method will join all active and held calls into a single
multiparty call, and then request the network to terminate the call on
the subscriber's end and transfer the control of the call to the
parties that are still in the call.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
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
Sometimes SUPL-server based A-GPS is not possible, e.g. if the module
doesn't have Internet connectivity. In such cases, the modem may
support injecting additional "assistance data" that may be downloaded
from the Internet using external means (e.g. WiFi), in order to keep
having a quick time to first fix.
We now support using this location assistance data, with the following
new API elements:
* A new mask of supported assistance data types is provided in the
SupportedAssistanceData property.
* A new list of URLs from where the aassistance data may be
downloaded is also provided in a new AssistanceDataServers
property.
* A new InjectAssistanceData() method is provided, to perform the
data injection in the module once it's been downloaded to the host
system.
We should only depend on GLib on the libmm-glib headers. Otherwise,
packages using just the core headers (e.g. ModemManagerQt) would also
need to build-depend on GLib and we don't want to enforce that.
cd ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src && ~/buildroot/output/host/usr/bin/arm-cortexa9_neon-linux-gnueabihf-g++ .... -fPIC -o CMakeFiles/KF5ModemManagerQt_static.dir/bearer.cpp.o -c ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/bearer.cpp
In file included from ~/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/ModemManager/ModemManager.h:41:0,
from ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/generictypes.h:27,
from ~/buildroot/output/build/kde-modemmanager-qt-v5.36.0/src/generictypes.cpp:23:
~/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/ModemManager/ModemManager-compat.h:23:18: fatal error: glib.h: No such file or directory
compilation terminated.
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
When this symbol is defined, e.g. via CFLAGS, building a program that
uses the ModemManager API will fail if the program references
deprecated symbols.
For now we just use it to keep gtk-doc-scan happy and avoid
unnecessary warnings.
