| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This new property will provide detailed information about the failed
connection attempt, or about the network initiated disconnection. The
property will be cleared only if a new connection attempt is
triggered, and so it can be used to investigate why a given attempt
failed without needing to be the one who triggered the attempt (e.g.
so that failures in NetworkManager-triggered connection attempts can
be investigated looking at the DBus API).
The property is built as a (ss) tuple, but the libmm-glib interface
provides methods to read this property as a GError.
|
|
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.
|
|
Some of the newly deprecated enum values were introduced in 1.14.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
It's not a generic interface, it's a feature interface, same as
messaging or location.
|
|
|
|
|
|
|
|
Include the new SAR interface in the build so that gdbus-codegen
generates support for it in libmm-glib as well as proper documentation
in the API reference.
|
|
|
|
|
|
This property will be TRUE if the bearer has the data session
connected through a multiplexed interface.
If the bearer is disconnected, or connected without multiplexing, the
property will report FALSE.
|
|
In addition to the amount of bearers a user may connect without
multiplexing enabled (the default until now), we now also expose the
maximum number of bearers a user may connect after enabling
multiplexing over one single network interface (if supported).
The method responsible for creating the MMBearerList is now also
subclassable, so that implementations supporting multiplexing can
provide their own version with their own thresholds.
|
|
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.
|
|
This commit includes D-Bus processing and documentation, but not any
modem access implementation.
|
|
|
|
The ModemManager1.Sim.PreferredNetworks property contains the preferred
networks (and access technologies, if available) configured to the
SIM card.
This commit implements preferred networks reading with AT+CPOL.
|
|
Probably not a big deal, since no one has asked for these in the past
years, but let's add them for completeness with the DBus API.
|
|
|
|
So that the gtkdoc-rebase step fixes the URLs to contain the correct
links; e.g.:
$ make dist V=s
make[8]: Entering directory '/home/aleksander/Development/foss/ModemManager/docs/reference/libmm-glib'
make \
top_distdir="../../../ModemManager-1.15.0" distdir="../../../ModemManager-1.15.0/docs/reference/libmm-glib" \
dist-hook
../ModemManager/ -> https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/ (914)
../gio/ -> https://developer.gnome.org/gio/unstable/ (2564)
../glib/ -> https://developer.gnome.org/glib/unstable/ (5534)
../gobject/ -> https://developer.gnome.org/gobject/unstable/ (499)
make[8]: Leaving directory '/home/aleksander/Development/foss/ModemManager/docs/reference/libmm-glib'
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/298
|
|
|
|
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 .actions file is generated by newer gtk-doc releases, we just
treat it as e.g. the .signals or .types files.
This is also already fixed in upstream gtk-doc:
https://gitlab.gnome.org/GNOME/gtk-doc/-/merge_requests/61
|
|
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
|
|
It's a private method, so add it in the Private subsection.
|
|
This exposes the new EID property of the SIM object on mmcli.
|
|
This provides a new D-Bus property on the Sim object that
exposes the EID of the SIM, if available.
|
|
|
|
This new method allows changing the SIM slot considered as primary,
when the modem supports multiple SIM slots.
The generic handling of this method will make sure that the modem
object and all its SIM objects are re-probed from scratch as soon as a
successful SIM slot switch happens.
Implementations may report MM_CORE_ERROR_EXISTS when the switch
doesn't need to happen (e.g. if the requested SIM slot is already the
active one).
|
|
The 'SimSlots' property exposes an array of SIM object paths, with one
array item for each available SIM slot in the system. If a valid SIM
card is found in a given slot, the path of the SIM object will be
exposed in the array item; if no valid SIM card is found, the empty
object path ("/") will be exposed instead.
The 'PrimarySimSlot' property exposes which of the SIM slots available
in the system is the one configured as being primary. In a Multi-SIM
Single-Standby setup, the primary slot will be the one corresponding
to the single active SIM in the system. In a Multi-SIM Multi-Standby
setup, the primary slot will be the one configured to act as primary
(e.g. the one that will be used for the data connection) among all the
active SIM cards found.
|
|
In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
|
|
|
|
Extended the ModemManager Signal interface to include 5G signal
information for RSRP, RSRQ and SINR via libqmi. Also extended mmci
to print 5G signal info.
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/203
|
|
Compiling the amount of bytes transferred and received during all
tracked connection attempts, as well as the total duration of all the
connections.
|
|
When we're reusing over and over the same bearer object, we can
provide statistical information about the number of connection
attempts that have been done and how many of them failed.
|
|
It's not used anywhere.
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/120
|
|
So that bindings know how to free the list of structs.
This commit ends up triggering an API break in the bindings generated
via GObject introspection, because the methods to access the items of
a MMModem3gppNetwork are no longer treated as Modem3gpp class methods.
E.g. instead of:
ModemManager.Modem3gpp.network_get_operator_code(network)
We should now do:
network.get_operator_code()
There is no API break in libmm-glib.
|
