| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
These values show the rates that have been negotiated with the network
during the PS domain attach.
These are not the current ongoing data rates associated to the network
usage at some given moment.
Includes updates by Aleksander Morgado to fix coding style issues and
add missing documentation items.
|
|
It stores the epoch timestamp of the current bearer session start.
If there is no connected bearer, it is set to 0 and not displayed
in mmcli output.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Includes updates by Aleksander Morgado to fix coding style issues.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Given as a list of items, because the bearer can be created with one
or more allowed authentication protocols.
|
|
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.
|
|
So that --help-all print all sections in the same way as the Help and
Application option groups.
|
|
mmcli-manager.c: In function ‘context_free’:
mmcli-manager.c:167:24: error: declaration of ‘ctx’ shadows a global declaration [-Werror=shadow]
167 | context_free (Context *ctx)
| ~~~~~~~~~^~~
mmcli-manager.c:51:17: note: shadowed declaration is here
51 | static Context *ctx;
| ^~~
...
|
|
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/99
|
|
This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
|
|
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.
|
|
In addition to the standard human-friendly output, we now allow a
machine-friendly key-value pair output, much easier to parse and use
by programs that look at the mmcli output.
This new key-value pair output should be treated as API from now on, so
third-party programs can assume the output is compatible from one
release to another.
|
|
Use always small letters.
|
|
|
|
mmcli is GPLv2+; that's what --version has always said and that's what the
README in ModemManager sources specifies:
License.
The ModemManager and mmcli binaries are both GPLv2+.
The libmm-glib library is LGPLv2+.
|
|
Even DHCP or PPP may have some IP details, like the link-local
address for IPv6 bearers.
|
|
|
|
|
|
|
|
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
|
|
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Actions on modems from specific interfaces, like 3GPP, will also need the modem
to be specified.
The new 'Common' option group will handle all options to specify objects.
|
|
|
|
In order to receive signals in the GDBusObjects retrieved from the
GDBusObjectManagerClient, we need to keep a reference of the client around.
|
|
|
