We can leave the relative paths to other books (e.g. '../glib' or
'../ModemManager') because running gtkdoc-rebase seems to be broken
since the 1.29 release, see:
https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/138
The tests spawn the service via GTestDBus framework and make
some test API call while checking libmm interface to verify
that informations are well propagated.
To be able to use the fresh built libmm typelib, I used a
wrapper script to set GI_TYPELIB_PATH (because DBus activation
process clean the environment so it is not possible to set
it directly in the file).
This requires also the install of libgirepository-dev and python3-gi
in the CI docker.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
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>
On some modem (for example SORACOM SC-QGLC4-C1) , the character set setup
step fails with "Unknown error" when the SIM card is missing or locked.
This leads to not expose Modem interface and not being able to unlocked
the SIM.
We should not consider this step as fatal but just issue a warning to let
other steps continue (which will let modem in failed state anyway).
Closes#289
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
We can rely on QMI indications when the signal quality and access tech
changes happen, instead of doing explicit polling.
The modem will run the signal quality retrieval once, and then just
rely on indications, with polling disabled:
ModemManager[278759]: <debug> [1606862198.230492] [modem1] signal strength (lte): -79 dBm
ModemManager[278759]: <debug> [1606862198.230520] [modem1] signal strength: -79 dBm --> 55%
ModemManager[278759]: <debug> [1606862198.230583] [modem1] access technology changed (unknown -> lte)
ModemManager[278759]: <debug> [1606862198.230654] [modem1] signal quality updated (55)
ModemManager[278759]: <debug> [1606862198.230675] [modem1] periodic signal quality and access technology checks not rescheduled: unneeded or unsupported
ModemManager[278759]: <debug> [1606862198.230692] [modem1] periodic signal checks disabled
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/231
When comparing bearer properties provided by the user versus loaded
from the modem, we shouldn't be very strict, e.g.:
* Password or other fields may not be readable from the device.
* Some fields may not apply at all (e.g. RM protocol for EPS bearers)
* NULL strings could be assumed equal to empty strings.
* If no explicit IP type specified, an IPv4 default may be assumed.
* If no explicit allowed auth specified, 'none' default may be
assumed.
These loose comparisons are applied when managing the initial EPS
bearer settings and status, and we keep the strict comparison only
during the connection attempt lookup of a bearer with certain
settings, as those bearer objects are all created in the same place
with the same rules.
The parse_vendor_pco_info() method was returning NULL without error if
the pco info string was empty.
Under this situation, the code would have tried to add a NULL MMPco
into the pco_list list, which is not desired.
Avoid this, by making sure a NULL return always sets an error.
This property (initially set to FALSE) controls whether QMI over MBIM
should never be considered. This property is set to TRUE for XMM-based
MBIM devices as they don't support QMI.
This fixes a probing delay of 15s on a Fibocom L850-GL device
(2cb7:0007) found in the Lenovo T14 Gen 1.
The establishing of a QMI connection was refused multiple time with
MBIM error OperationNotAllowed. Only the timeout of 15s for this
connection resumed the probing.
The properties in the MMBroadbandModemMbim are only installed when
WITH_QMI and QMI_MBIM_QMUX_SUPPORTED are set. Actually, this should only
disable the PROP_QMI_UNSUPPORTED but as this is the only property this
avoids the "unused variable 'self'" warnings/errors when trying to
compile set_property and get_property without QMI support. This can be
changed once other properties are needed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/284
We had all the logic in place... but we were never actually enabling
the signal strength indications because the `enable` flag in the
context was never set.
The bug was introduced back in May 2018, and released with 1.10.0.
Fixes baefe53ab9
Do not fail to detect an error response with a call or text incoming. This happens during port probing when there's no URC parsers installed in the serial port. This probably will not happen when the serial port was managed by the modem object.w
Do not fail to detect a valid response with a call or text incoming.
This happens also during port probing when there's no URC parsers
installed in the serial port. This probably will not happen when the
serial port was managed by the modem object.
If e.g. a bearer with IPv6 configuration has DNS servers but exports
its link-local address, MM will avoid giving it the "static" method
type, and instead fall back to the "dhcp" type. However, it may
still have DNS information. Therefore, the comment that "method" is
the only property on configuration with type DHCP is misleading.
Enabling/Disabling/Changing/Sending the PIN1 lock is usually limited to
3 retries. If these attempts are exhausted, the modem is puk_locked.
We reprobe the modem to get rid of any unwanted interfaces and move
to a locked state.
If the lock status cannot be read during a puk unblock attempt, reprobe
the modem. It is likely that the SIM was permanently blocked if the lock
status cannot be read.
When there are multiple ports with the same purpose (e.g. multiple net
data ports, or multiple QMI control ports), sort them by name by
default.
The port order does not make any difference for ports that have
flagged with a specific purpose (e.g. AT primary).
The sorting is done both in the internal lists and when looking up
ports with find_ports().
It will not be automatically enabled by the implicit
--enable-all-plugins; instead, it must be explicitly enabled with
--enable-plugin-qcom-soc.
This plugin only makes sense under very specific SoC builds, so there
is no point in always building it by default. It should be explicitly
requested only in those SoC builds that are really going to make use
of it (e.g. postmarketOS).
This plugin implements support for old Qualcomm SoCs like the MSM8916
or the MSM8974, where:
* control ports are available via RPMSG channels exported as devices
e.g. with rpmsgexport:
https://github.com/andersson/rpmsgexport
* network ports are exposed by the bam-dmux kernel driver:
https://github.com/msm8916-mainline/linux/commits/bam-dmux
Adding support for newer Qualcomm SoCs (e.g. QRTR+IPA) could be done
in a similar way on this very same plugin.
This plugin is the first and only one that implements support for a
modem device that is "built in" the system, as opposed to external
modems that may be available via USB or PCI.
The ID_MM_PHYSDEV_UID based udev tags provided by the plugin provide
the logic to bind all the SoC ports together in the same modem object,
and therefore ID_MM_PHYSDEV_UID should not be used by users to
override the ones set by the plugin.
All "rpmsg[0-9]*" ports that are considered part of the modem are
flagged as candidate, ignoring the parent "rpmsg_ctrl[0-9]*" ports on
purpose. This setup therefore assumes that the channels have been
exported already as devices (e.g. using rpmsgexport).
libqmi 1.27.2 is required to support the "WDS Bind Data Port" message.
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate with
the integrated modem via shared memory (SMD channels). This is similar
to QRTR on newer SoCs, but without the "network" layer. In fact, the
older SoCs also have QRTR, but the modem QMI services are not exposed
there.
The mainline Linux kernel exposes SMD channels via the "remote processor
messaging bus" (rpmsg). Through special IOCTL calls it is possible to
create a char device for a rpmsg/SMD channel. We can then use these to
send QMI/AT messages to the modem, much like the ordinary serial char
devices when using a Qualcomm modem through USB.
This commit introduces support for the new 'rpmsg' subsystem, which
allows exporting QMI-capable and AT-capable ports.
By default NO rpmsg port is flagged as candidate, it is assumed that
the plugin adding support for the rpmsg subsystem will add specific
rules to do so (e.g. so that non-modem ports are explicitly not
flagged as candidate).
All rpmsg ports will be probed for AT or QMI capabilities, unless
explicit port type hints (e.g. ID_MM_PORT_TYPE_QMI or
ID_MM_PORT_TYPE_AT_PRIMARY) are set.
These changes are highly based on the initial integration work done by
Stephan Gerhold <stephan@gerhold.net> in postmarketOS, see:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
In addition to loading port and device properties, we now also allow
loading sysfs properties that are assumed to be static (i.e. their
values won't change since loaded the first time).
Allow plugins to specify a QmiSioPort value to bind to. This is used
e.g. in the RPMSG+BAM-DMUX setup in order to allow any RPMSG port to
control all the available net ports.
Fixes an issue where (5+8n)-character long SMS messages received on a
CDMA network would be dropped with a "cannot read user data" error,
while other length SMS messages would be delivered fine.
Fix thanks to Peter Hunt
