| Age | Commit message (Collapse) | Author |
|---|
|
Even if some fields wouldn't apply to some modem, we're always
including all in the output so that clients can assume the fields are
always given.
Fix adding the 3GPP EPS related fields unconditionally.
|
|
This method allows users to modify the settings used during the
initial LTE attach procedure.
|
|
This property shows the settings stored in the device to be used
during the initial LTE attach procedure.
|
|
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.
|
|
This string shows the runtime version of the ModemManager daemon.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/94
|
|
This patch fixes the following compiler warning:
mmcli-output.c:783:19: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
aux = strlen (section_infos[field_infos[item_l->field].section].name);
^
|
|
This patch fixes the following issue with string conversion of a MMCallStateReason enum:
mmcli-call.c:160:88: error: implicit conversion from enumeration type 'MMCallStateReason' to different enumeration type 'MMCallState' [-Werror,-Wenum-conversion]
mmcli_output_string (MMC_F_CALL_PROPERTIES_STATE_REASON, mm_call_state_get_string (mm_call_get_state_reason (call)));
~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
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.
|
|
The --location-get action provides full location information from all
sources, which is better than per-source actions, as those were anyway
using the same API method to load location information as the global
one.
|
|
The Simple.GetStatus() method is useful for simple DBus clients that
don't need all the information associated to the modem, just the most
important bits. But, in our case, the information provided by this
method is already given by the standard modem info output, so it is
totally redundant.
|
|
This method is completely unnecessary as we have the readable Bearers
property already in place, so let's deprecate it.
Worth noting that the mm_modem_list_bearers() async/sync methods in
libmm-glib were not really using the ListBearers() method anyway, they
are using the property directly. These methods are NOT deprecated,
because they allow us to get a list of MMBearer objects, instead of
just the list of DBus paths that we get when reading the Bearers
property directly.
We also remove --list-bearers from the mmcli operation list as we have
already the same information in the standard modem output.
|
|
Each group of items should have a separator.
|
|
At this point we want the values enclosed between single quotes,
e.g. so that the fields are parsed easier by scripts.
This issue will not have any practical relevance as soon as the
key-value pair output support is merged.
|
|
|
|
|
|
Use always small letters.
|
|
Remove the redundant declaration of which slipped into the code in commit
091bf4dbd811 ("api: support location assistance data").
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
|
|
This is just to consolidate the output w.r.t. similar fields in
e.g. the Messaging or Location interfaces.
|
|
All these values are usually specified in hex, not in dec.
|
|
Devices will expect SUPL server given as either IP:PORT or FQDN:PORT,
so just avoid saying we require a 'URL' because it's not true.
We will use a new helper method to parse and validate user-provided
SUPL server address.
|
|
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 "location area code" field is given in GSM/UMTS networks
exclusively. LTE networks use the concept of "tracking area code"
instead.
This patch updates the Location interface to Provide separate fields
for LAC and TAC, instead of giving TAC values in the LAC field.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Looks like the preprocessor doesn't choke when using #if WITH_UDEV and
it isn't defined to any value, but anyway, better explicitly say that
we're checking if it's defined or not.
|
|
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
|
|
|
|
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
|
|
|
|
Introduce "sms only" and "CSFB not preferred" home/roaming states to be reported
for the CS context, while already registered on LTE.
Based on 3GPP TS 27.007 v13.5.0.
|
|
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
|
|
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
|
|
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device. This
logic was already in place, what we do now is avoid calling it the 'sysfs
path' of the physical device, because we may not want to use that to identify
a device.
This logic now also enables the possibility of "naming" the modems in a unique
way by setting the "ID_MM_PHYSDEV_UID" property in the "usb_device" that owns
all the ports.
E.g. a custom device has 4 modems in 4 different USB ports. The device path of
each USB device will always be the same, so the naming rules could go like this:
$ vim /usr/lib/udev/rules.d/78-mm-naming.rules
ACTION!="add|change|move", GOTO="mm_naming_rules_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.1", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-1"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-2"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-3"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-4"
LABEL="mm_naming_rules_end"
Each of the modems found will have a unique UID retrieved from the previous list
of rules. Then, "mmcli" has also been updated to allow using the UID instead of
the modem DBus path or index, e.g.:
$ sudo mmcli -m USB-MODEM-1
/org/freedesktop/ModemManager1/Modem/0 (device id '988d83252c0598f670c2d69d5f41e077204a92fd')
-------------------------
Hardware | manufacturer: 'ZTE CORPORATION'
| model: 'MF637'
| revision: 'BD_W7P673A3F3V1.0.0B04'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: '356516027657837'
-------------------------
System | device: 'USB-MODEM-1'
| drivers: 'option'
| plugin: 'ZTE'
| primary port: 'ttyUSB5'
| ports: 'ttyUSB5 (at)'
...
$ sudo mmcli -m USB-MODEM-1 --enable
...
|
|
Commit 001f35234e16d7aeb2ed1282ba3b57aea73c5a9e fixed this very same thing in
all the other interface actions, but 3GPP USSD actions were not fixed.
https://bugs.freedesktop.org/show_bug.cgi?id=97954
|
|
|
|
|
|
So that appending a new item in the list only inserts one new line (i.e. the
last $(NULL) is the last item always).
|
|
|
|
Not making them '--location-enable|disable-signal' because that's the pattern
used to enable/disable location sources. Instead, use the '--location-set-*'
pattern, as that is what we're already using for the other location setup
update.
|
|
The default setup uses a refresh time of 30s, which means that even if the GPS
location updates are received at a higher frequency, the DBus interface will
still expose at most one update every 30s.
This patch includes a new "SetGpsRefreshTime()" method in the Location
interface, which takes a single 'u' parameter, specifying the refresh rate to
use, in seconds. This method also allows 0 being passed, which will make the
implementation to publish the GPS location updates are soon as ModemManager
detects them.
Along with the new method, a "GpsRefreshTime" read-only property is exposed
to specify the refresh time in effect.
The new method and property will only be applicable if the device has GPS
capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=89924
|
