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.
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.
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.
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.
Using an intermediate constant variable breaks compilation with C
compilers, as these variables cannot be used as initializers.
Instead, define a deprecated type and cast all deprecated symbols to
that type. We lose the information about what the new replacement
symbol is, but we don't break compilation.
E.g.:
test.c: In function ‘main’:
test.c:8:5: warning: ‘MMModemBandDeprecated’ is deprecated [-Wdeprecated-declarations]
printf ("band: %d\n", MM_MODEM_BAND_U2100);
^~~~~~
Those Roman numeral suffixes in MM_MODEM_BAND_EUTRAN_* were replaced
with 1, 2, 3, ..., etc. This patch adds a compatibility header,
ModemManager-compat.h, to alias the old MM_MODEM_BAND_EUTRAN_* values to
the new values.
We will expose a new 'Ports' property listing all ports currently known by a
given modem. Ports which are not used but are detected as being part of the
modem will be listed with an 'unknown' port type.
This change uses the new 'MMModemPortType' enum and the new 'MMModemPortInfo'
helper struct to handle these values in libmm-glib. The already available
'MMPortType' enum hasn't been re-used for the interface because it contains
values that we don't need (e.g. IGNORED).
The port list is now also included in the modem information command of mmcli:
$ sudo mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '97b7b99e3e2bea103880545b619fb05a3cc81b26')
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'cdc-wdm0'
| ports: 'ttyUSB0 (qcdm), ttyUSB1 (at), cdc-wdm0 (qmi), wwp0s29u1u4 (net)'
https://bugzilla.gnome.org/show_bug.cgi?id=702678
We don't want to support only 'relative' validity, so don't assume that the
Validity property will always be a uint32 value.
Instead, we define the Validity propery as '(uv)' tuple, where the first value
(a MMSmsValidityType) specifies the type of validity, and the second value is
a variant formatted accordingly to what the validity type specifies (e.g. a
uint32 value if the type is MM_SMS_VALIDITY_TYPE_RELATIVE).
For bearers using STATIC or DHCP IP method, the modem itself is the one
negotiating authentication with the network. The new `allowed-auth' property
allows users to specify which authentication method(s) are allowed to be used.
See the following NetworkManager commit for more reference:
commit 34aef8aaaa09b7473b9496aa49e550bd2def03f8
Author: Andrew Bird <ajb@spheresystems.co.uk>
Date: Thu Mar 15 16:19:43 2012 -0500
Instead of using a predefined set of string values for 'ip-type' in
Modem.CreateBearer() and Simple.Connect(), we'll use an enumeration. The
implementation will then need to convert the requested IP family type to e.g.
the correct PDP type in 3GPP modems.
This change also consolidates the use of enums in dictionary properties when
possible to do so, as with the Rm Protocol.
