CBM isn't as complicated as SMS, and the CBM class itself doesn't
need to be overridden by QMI/MBIM/etc. Now that the log parent
and connection binding no longer require MMBaseModem we can flatten
the CBM object creation and remove usage of MMBaseModem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
AT docs for many (most?) Quectel devices state that QPOWD=1 receives
the OK response very quickly but the caller must wait for the
POWERED DOWN URC to avoid data loss. Do that.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
When matching profiles ignore disabled ones. When activating a
specific profile index, return an error if that profile is marked
as disabled.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Previously, a disabled profile would cause Profile Manager interface
enabling to fail because get_profile_settings_ready() returned an
error for disabled profiles.
But 3GPP profile objects already have support for the enable/disabled
setting, so just hook that up and stop returning an error for disabled
ones.
This allows successful initialization of the 3GPP Profile Manager
on devices that contain disabled profiles.
While we're at it, allow creating disabled profiles, and changing
profiles back and forth from enabled<->disabled.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
We want ports to be closed as early as possible; so make sure they
are closed in dispose() which is run explicitly by MMDevice when
cleaning up and removing the modem. Otherwise they could stay
open longer than we want, causing problems for suspend/resume.
This caused problems with suspend because cancelling the
MMBaseModem's cancellable triggered an idle handler that held
a reference to the modem, preventing finalize() from running
until after the suspend code was finished, thus preventing
ports from being closed and cleaned up. Closing them in
dispose() handles this.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
base_modem_invalid_idle() needs to keep a reference to the
MMBaseModem until its done. But if the modem is cancelled during
removal right before we're trying to forget about it, keeping
that reference can prevent everything getting cleaned up by
MMBaseModem's dispose() until after the mainloop has run again
and all our removal operations are supposedly complete.
MMDevice uses an explicit dispose() trigger that mitigates
most of this (and requires it for other reasons, like breaking
reference cycles between the modem and it's various child
classes) but it's somewhat error-prone to keep the modem
around if we don't really need to.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Every use of mm_device_remove_modem() was already trying to cancel the
modem's canellable, so let's just put it there and simplify the callers.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This refreshes operator information after manual registration. QMI and
MBIM implementations return operator info along with registration info
so they handle this easily, while with AT-based devices we must run
additional commands to retrieve that after the manual registration has
finished.
Suggested by: Kirill Buksha <kirill.buksha@axians.rs>
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/971
Signed-off-by: Dan Williams <dan@ioncontrol.co>
When an outgoing call is created and added to the call list its state
is UNKNOWN. The call list emits the ADDED signal which MMIfaceModemVoice
listens for to check whether to begin polling call state.
But since UNKNOWN is not an in-progress call state polling isn't started.
And nothing was rechecking whether to start polling when the call state
changed to something other than UNKNOWN.
Do that so that we can track call progress as it dials out and is
answered.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Missing ! for strncmp() meant the test was backwards and would
erroneously report 1xRTT and EVDOr0 when those access technologies
were not in use.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Dell Snapdragon X62 before FCC Unlock reports no radio interfaces
from QMI and no device capabilities from MBIM. Instead of asserting
in mm_filter_supported_modes() when called from
mm_supported_modes_from_qmi_supported_modes_context() gracefully
handle the lack of supported modes.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The script was combining all commit messages into one due to the quoting
of "${COMMIT}", rather than leaving unquoted and picking each individual
commit from the space separated string.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
MBIM modems report RSSI and sometimes don't report more detailed RSRP
and SNR info their MBIMex v2 signal-state replies. RSSI gets reported
for every other access technology, and while it's not as good a signal
indicator as the others, we might as well show something.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Consistently interpret the modem's reported custom data class when
loading current mode, supported mode, supported capabilities,
setting current mode, and current access technology.
Normalize the data class to include any custom data class immediately
after reading it from any MBIM message. De-normalize it when sending
back to the modem when setting current modes so the modem receives
MBIM_DATA_CLASS_CUSTOM for the custom mode.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/937
Signed-off-by: Dan Williams <dan@ioncontrol.co>
For modems that need more time to respond to AT port probes (like some Telit devices,
and Cinterion-based Telit MV31/MV32) allow a custom number of AT probe tries on a
per-port basis for generic probing, or plugins that opt into this functionality.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the old IMSI was unavailable because the SIM was locked, but now
is available because the SIM was unlocked, don't treat the SIM
properties change as a hotswap that may trigger dropping and re-probing
the modem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If multiple plugins are selected for probing a modem with AT probes,
earlier plugins may only request some probes but not all. When
those probes complete successfully, subsequent plugins won't re-do
the probes that were already completed, but jump to ones that
haven't yet been done.
For example, plugin A may request only AT probes but plugin B
may request AT, AT_PRODUCT, and AT_VENDOR. Plugin B will start
with AT_PRODUCT probes because plugin A already completed the AT
probe.
The code in probe_step() only opened the serial port for the
AT probe, I guess assuming that all AT-type probes would be
done in sequence. But in the above scenario they are not.
Instead, make sure the port is opened for all AT style probes
that have not yet been executed.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Add some mmcli D-Bus timeout slack, making them slightly higher than the
ModemManager internal timeout, to ensure the cli doesn't time out the
D-Bus call when MM succeeds.
For 3GPP scan, some modems appear to have internal 5 minute timeouts,
so ensure MM doesn't time out right before the modem returns results:
ModemManager[282578]: <dbg> [1741054422.321400] [ttyUSB2/at] --> 'AT+COPS=?<CR>'
ModemManager[282578]: <wrn> [1741054722.247806] [modem1] failed scanning networks: Serial command timed out
ModemManager[282578]: <dbg> [1741054724.119770] [ttyUSB2/at] <-- '<CR><LF>+COPS: (1,"T-Mobile","T-Mobile","310260",0),,(0,1,2,3,4),(0,1,2)<CR><LF><CR><LF>OK<CR><LF>'
Signed-off-by: Dan Williams <dan@ioncontrol.co>
With the FDO CI templates, the first container used must
be .fdo.container-build@ubuntu which builds the actual
container the rest of the pipeline can use with
.fdo.distribution-image@ubuntu.
.fdo.container-build@ubuntu uses a static 'image:' tag for
its job base image and then pushes to the project registry.
If the first job incorrectly uses .fdo.distribution-image@ubuntu
instead, it appears to fail for MR branches because that target
uses CI_REGISTRY_USER as part of the 'image:' tag which gitlab
sets to the username of the submitter. Which of course fails
because that user has never built the image before...
Using Docker executor with image registry.freedesktop.org/<username>/modemmanager/ubuntu/20.04:2023-01-03.1 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.freedesktop.org/<username>/modemmanager/ubuntu/20.04:2023-01-03.1 ...
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Since we're also now reading responses we need to check sender
credentials to make sure we're talking to the kernel, and not
some other process spoofing netlink.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Seen on a Qualcomm-based Quectel EG915Q on the diag port:
ModemManager[34547]: <dbg> [1732077670.330527] [ttyUSB0/at] <-- ' \0\0\0\8\0\0\0\2\0\0\0\0`%\160$"\6\169\128\200\1\30\197\142\0G\184\225\128\0\1+\127\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254'
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Referenced commit broke custom init flows because the AT port
was not opened when custom inits were run, which was the case
before the commit landed.
Rework probing flow to follow a step model like much of our
other code, and ensure that the AT port is opened as part
of the custom init flow.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the system and modem are independently powered, a system restart may
leave one of the modem's AT ports in PPP mode. On restart this may cause
AT probing to fail. The modem may terminate PPP after receiving bogus
HDLC frames from QCDM probing (since PPP also uses HDLC framing), and
return "NO CARRIER". We can use this to restart AT probing now that
PPP is down and auto-detect the expected additional AT ports.
Feb 08 20:22:53 ModemManager[385]: <debug> [1675887773.887574] [ttyUSB2/at] <-- '\8\158\239~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.215054] [ttyUSB2/at] <-- '\8\214\137~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.851349] [ttyUSB2/at] <-- '\8\250\177~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.576776] [ttyUSB2/at] <-- '\8\168u~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.612694] [ttyUSB2/at] <-- '\8w\25~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.862886] [ttyUSB2/at] <-- '\8!&~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.614747] [ttyUSB2/at] <-- '\8%\254~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686207] [ttyUSB2/probe] port is not AT-capable
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686447] [ttyUSB2/probe] probing QCDM...
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.725483] [ttyUSB2/qcdm] --> 7e 00 78 f0 7e
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.880941] [ttyUSB2/qcdm] <-- 0d 0a 4e 4f 20 43 41 52 52 49 45 52 0d 0a
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Open the AT port from the regular port probe flow rather than doing
that one-off at the beginning of probing. That lets us re-open the AT
port later if needed, based on QCDM/QMI/MBIM probing results.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Dan Williams