When passing known_lock=UNKNOWN to mm_iface_modem_update_lock_info()
we actually do want to ask the modem itself for locks instead of
checking the cache. For example, when an unknown error is returned
after performing PIN/PUK operations, the cache value may well be
NONE if that was the prior lock state, and that bypasses the modem
which might now be locked. Thus the state gets messed up.
Reproducer is to send 'ChangePin' with the wrong "old" PIN 3 times,
then send a wrong PUK. No error was returned from mmcli and
the modem's lock state was shown as 'none'.
The Pantech UML290 takes a horribly great time to initialize the SIM, and
therefore we may even be losing the 3GPP capabilities as the SIM is not
detected during the initial checks:
load_unlock_required_ready(): Couldn't check if unlock required: 'SIM failure: QMI protocol error (37): 'UimUninitialized''
current_capabilities_internal_load_unlock_required_ready(): Multimode device without SIM, no 3GPP capabilities
To avoid this, let 'UimUninitialized' be a retriable error.
QMI modems are incorrectly ignoring IMEI/ESN/MEID numbers that start with a
'0'. Fix this up. Seen on an AT&T Beam (340u)
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
Instead of providing explicit dependency rules to generate the enum types
support files before they're first used, just pre-generate them before building
anything. Maintaining the explicit dependency rules is not really worth it.
This message gets printed for all netdevs and ttys, including most
machines normal ethernet/Wi-Fi interfaces. It seems a bit less critical
than 'warning' level would indicate.
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:19.0': not supported by any plugin
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0': not supported by any plugin
If for any reason the modem is in OFF state and still can talk to the modem,
allow running the remaining transition requests to LOW or ON. This can happen
for example for modems that use CFUN:0, i.e. which can still go online with
CFUN=1.
https://bugs.freedesktop.org/show_bug.cgi?id=89368
We really do need a wait time to make sure most ports are exposed by the
kernel, so that plugin filters based on "forbidden-drivers" work correctly. E.g.
the "gobi" plugin now flags as forbidden the "qmi_wwan" driver, which means that
modems exposing both TTYs and QMI/WWAN ports should never be handled by the Gobi
plugin.
Some new devices, like the Dell DW5770, will return an internal error when
trying to bring the power mode to online. We can avoid this by sending the
magic "DMS Set FCC Auth" message before retrying.
Bumping libqmi version to 1.13.4, which is the one that supports this new
message.
https://bugzilla.kernel.org/show_bug.cgi?id=92101
MM probing appears to make 'visor' module die; and anyway
most of the devices driven by 'visor' are not phones, and
of the 3 that are phones they are so old (2002 - 2005 era)
that nobody is likely using them for dialup anymore.
http://www.spinics.net/lists/linux-usb/msg120483.html
Since commit 2d700043ab ("core: use g_unix_signal_add() for more
reliable Unix signal handling") we no longer have to stick to
signal-safe functions in the SIGTERM/SIGINT handler.
Use exit() to terminate so that the clean-up functions are ran and code
coverage data gets written into files.
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.