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>
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>
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>
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>
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>
Allows setting the renamed `ID_MM_QUALCOMM_FIREHOSE` and
`ID_MM_QUALCOMM_SAHARA` environment variables for all devices.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
The CBMs are read via unsolicted events for which we register
an event handler.
We don't enable unsolicted events explicitly as this already happens
via the `+CNMI=*,*,2,*,*` whens setting up unsolicted events in
`modem_messaging_enable_unsolicited_events` (ETSI TS 127 005).
The modem state property update was happening at disabling task context
free time, after the actual task completion has happened.
Avoid wrong assumptions on the modem state value in operations
scheduled after the task completion, in the same way as done in the
enabling sequence.
The modem state property update was happening at enabling task context
free time, after the actual task completion has happened. Due to this,
scheduling a new enable request right after finishing one would end up
with the logic asserting, as the new enable operation would be
scheduled while the modem was still reporting "enabling" state.
ModemManager[7673]: <inf> [1722359278.131123] [modem0] processing user request to enable modem...
**
ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached
Bail out! ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached
Aborted
The main issue here is how to select the id of the context that is
used for attach in the modem.
We will assume that the lowest cid value for the IP range returned in
the CGDCONT=? test is the one used for the attach context. This
assumption works with modems following the 3GPP specs (with cid=0) and
also in Qualcomm based modems (with cid=1).
The whole codebase is updated to assume the MMBaseModem AT operations
require an object implementing the MMIfacePortAt interface, instead of
a MMPortSerialAt object.
In the places where we know the port is a MMPortSerialAt, e.g. when we
query explicitly for the primary or secondary serial AT port, we will
use an explicit MM_IFACE_PORT_AT() cast when calling the AT command
method.
In the places where we get_best_at_port() we're going to assume that
we don't know the port type. This method will be updated in a follow
up commit to support the MMIfacePortAt interface as well.
We should not blindly assume that peek_port_primary() always returns a
valid port, because the device may have been ejected while the AT
sequence is running.
Instead, keep a valid port object reference in the operation context,
and use it in all the AT command requests. The requests will fail if
the device has been ejected, but the port object reference will be
valid and the daemon won't crash.
Rework the AT string quote operation to build the output with the
GString helper, instead of manually calculating how many bytes we'll
need in the output. It just makes it clearer.
We cannot assume that the ports may be peeked after the AT sequence
has finished, because they may have been already removed. We can store
a full port reference instead, to ensure the validity of the objects
at that time.
==19351== Process terminating with default action of signal 5 (SIGTRAP)
==19351== at 0x4A1DB24: g_logv (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A1DDB2: g_log (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x28B54E: mm_port_get_device (mm-port.c:62)
==19351== by 0x1B1247: modem_messaging_enable_unsolicited_events_secondary_ready (mm-broadband-modem.c:7373)
==19351== by 0x4BA37D8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==19351== by 0x4BA381C: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==19351== by 0x4A157EE: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A68D27: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x4A14E52: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==19351== by 0x176B91: main (main.c:236)