This very peculiar case can happen when an intermediate initiliazition step
of a modem fails.
The ModemManager daemon should always expose the modem interface but let not
assume that in mmcli and protect these calls.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
If the device supports multiple SIM slots, when the user provides a
PATH or INDEX of a SIM card to use, don't look for the SIM object only
in the 'Sim' property, also look for it in the 'SimSlots' property.
When a system only has one single modem, it's convenient to just look
for the first available modem or SIM object, instead of needing to
provide the full path or the exact index number.
This improvement allows users to use the "any" keyword, or any of its
substrings (e.g. "an" or even "a") to match the first available object
of the requested type.
E.g.:
$ mmcli -m a
--------------------------------
General | dbus path: /org/freedesktop/ModemManager1/Modem/0
| device id: 1a48f1180f1fb0166d91f7b139d027136b59ba63
--------------------------------
Hardware | manufacturer: Sierra Wireless Inc.
| model: Sierra Wireless EM7345 4G LTE
...
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/196
The user may specify DBus objects in several ways, e.g. with full
object paths, just with the object numeric ids, or in some other cases
with the full device UID.
Setup one single method to process this info for all object types, so
that it's also easier to add new lookup methods for all at the same
time.
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.
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.
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
...
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+.
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.
So, these two are equivalent:
$> mmcli -b 0
$> mmcli -b /org/freedesktop/ModemManager1/Bearer/0
and also this two:
$> mmcli -s 0
$> mmcli -s /org/freedesktop/ModemManager1/SIM/0
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.
