There are cases where the user wants to configure some actions
to be run on a modem before ModemManager takes over full control.
The new "modem setup" dispatcher scripts allow running operations
in the modem after the port probing has happened and we know which
ports are usable in the device.
The scripts may e.g. change device configuration, enable modem
logging infrastructure, or any other process that would otherwise
conflict with MM's own modem management operations.
This uses the proprietary `^NDISSTATQRY` instead of the default
`+CGDCONT` command, as the latter might return diffrent results
(i.e. reporting v6 support, that can't be used via NDIS).
Also add a fallback to `+CGDCONT?` for older modems that don't
support ^NDISSTATQRY.
Refactor the loading/setting of supported/current modes/bands,
mostly to enable LTE support via ^SYSCFGEX.
This unfortunately requires many changes at once, as these methods
use the same AT commands and their fallbacks.
When sending or storing an SMS, the per-part operation is itself split
into two steps: first we send the AT command specifying the index, and
then we send the actual PDU data with a raw command. We must ensure
that the raw command is sent exactly in the same port as the AT
command.
Since commit 63dd4ad2 it is possible that the GPS interface is in use at
the time of modem reinitialization so it should not be stopped in such
case.
Otherwise "mmcli --location-status" will still say that GPS is enabled but
no GPS traces are going to be coming.
This avoids the "port in device added after device probing has already
finished" warning, and also the creation of modem objects for single
port devices.
Currently, the operator description update is only triggered once in the
entire update process. But this can lead to a operator description
updated at the wrong time. And is therefore possibly wrong.
The deprecated API call 'qmi_client_nas_get_serving_system' always triggers
an update of the operator description in there subfunction of the callback.
This is missing for the API call 'qmi_client_nas_get_system_info'. To solve
this, an update is now also triggered in the subfunction callback if there
is new system info available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
When using a modem with the qmi plugin, the operator description is only
set once for the current modem object. This is the operator description
of the mobile network to which the modem has first established a connection.
The operator description will no longer be updated even though on a
reconnection with a different mobile network.
Normally this is not a problem, as the SIM card usually dials into the
home network and stays there. But if an IoT SIM card is used, then this
is a problem because the operator description is no longer updated.
To fix this, the 'current_operator_description' is always loaded on
'modem_3gpp_load_operator_name' regardless of whether an operator
description has ever been set.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
The modem location interface loads modem location capabilities only during
the very first initialization of this interface.
On each later reinitialization it skips loading these capabilities from
modem, however it still goes through the whole interface initialization
state machine.
This state machine uses its own "ctx->capabilities" field for temporary
capabilities storage, which is set to MM_MODEM_LOCATION_SOURCE_NONE at the
start of the initialization process.
However, if we aren't actually loading modem location capabilities because
we're only reinitializing the interface we still need to set this
"ctx->capabilities" field to the existing (previously loaded) modem
location capabilities.
Otherwise the next interface initialization step (validation) will
permanently disable the whole location interface.
The generic MBIM modem implementation does not have location
capabilities support, so the relevant function pointers in the
interface are NULL.
Fixes: 306566ad7e
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.
Nero
Aleksander Morgado
Oliver Kästner
Aleksander Morgado
Maciej S. Szmigiero
Florian Eckert
Dan Williams
Steve Leung