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>
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 want to ensure that all errors reported via DBus operations are
normalized to MM-specific errors.
We don't want to return QMI or MBIM specific errors, as those are
protocol specific and we don't want DBus clients to need to rely on
knowing which is the protocol in use by the device.
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
If the modem is connected using the primary port, we can just rely on
the secondary port.
# mmcli --call 0 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Connected: Cannot run sequence: port is connected'
If we get one of the in-call termination errors before ATD replies OK,
we need to cancel the start() operation right away and return an
error to the caller.
Otherwise, the Call will be reported as "terminated" right away, but
the caller would not get an error back until 90s later:
$ sudo mmcli --call 0 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Serial.ResponseTimeout: Serial command timed out'
The in-call unsolicited events and the in-call audio settings are
managed exclusively at modem level, and no longer at call object
level. This is because these two things are applicable to all calls
that may be active at the same time.
The standard says a RING or CRING should be emitted whenever the
network sends an incoming call notification, which is nation-specific:
"Interpretation of indications from the network to determine what
constitutes a "ring" is defined by national regulations. This
result code should be repeated each time the network repeats the
incoming call indication." -- ITU-T Rec. V.250, p. 42
On the giffgaff (O2) network in the UK, a SIMCom SIM7100E modem emits
RING indicators every six seconds. The current timeout is only five
seconds resulting in a stream of timed-out ModemManager call objects
whenever there is an incoming call. To fix this, we increase the
timeout to ten seconds.
The handler assumes the regex sub-expressions each have the same index
so they need to be within the same set of parentheses rather than each
individually parenthesised. Without this fix, call state changes are
missed.
Modems that require specific commands to setup or cleanup the audio
channel as soon as a call is ongoing can subclass these two new
methods.
The setup() method is considered part of the call start/accept
process, and so if it fails, the whole operation will fail.
The failures in the cleanup() method will be reported in the log, but
otherwise ignored, as this operation may be executed without any
user intervention (e.g. if the remote party hangs up).
So that we setup in-call events as soon as we get the incoming call
ringing in. This allows us to have plugin-specific implementations
e.g. reporting call termination when the remote caller hangs up.
Calls created from property bundles are always outgoing, while calls
created as input events from URCs during runtime are always incoming.
This change makes it mandatory to provide at least direction of the
call when the object is created, leaving the number as an optional
property that may or may not be known in advance (e.g. it would be
optional only for incoming calls).
The Voice interface logic must always use the create_call() object
from its own interface to create call objects, as that is the method
that plugins can subclass to provide plugin-specific call objects.
This applies to both incoming and outgoing calls.
In order to detect state changes while we're in-call, we have to
monitor the standard connection errors we're used to, but have them
processed as URCs instead of as responses to ATD requests.
The most detailed call state transition flow for a new outgoing call
would be:
UNKNOWN -> DIALING -> RINGING -> ACTIVE
But, if the modem doesn't support reporting intermediate states
(e.g. DIALING or RINGING) then a successful start() should imply
getting into ACTIVE state right away.
For now, only the Huawei plugin implements the detailed transition
support, so make them configurable via call object properties.
Don't do any call state update on the generic implementation of the
commands, do it in the common interface logic exclusively.
We were doing the state updates in both places.
Call information only lives in the ModemManager logic, there is no
associated date stored within the device itself. Therefore, simplify
everything by assuming there is nothing to remove.
Looks like this logic was implemented because it was originally based
on the SMS management logic, but for SMS we do have to remove
them (the stored PDU parts) from the device.
Make sure the async task is always finished, even when
mm_base_modem_at_command_finish() returns an error which is not
MM_SERIAL_ERROR_RESPONSE_TIMEOUT.
Don't return FALSE when call is successfully accepted, otherwise the
caller will get very confused:
ModemManager[19952]: <debug> [1528968478.344338] (ttyACM2): --> 'ATA<CR>'
ModemManager[19952]: <debug> [1528968478.361986] (ttyACM2): <-- '<CR><LF>OK<CR><LF>'
(ModemManager:19952): GLib-GIO-CRITICAL **: 11:27:58.387: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
And also, make sure the async task is always finished, even when
mm_base_modem_at_command_finish() returns an error which is not
MM_SERIAL_ERROR_RESPONSE_TIMEOUT.
Keeps build with GCC 8 happy.
mm-base-call.c:758:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-call.c:822:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-sms.c:908:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-sms-list.c:331:25: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
mm-iface-modem-messaging.c:1210:21: warning: variable 'storage_ctx' set but not used [-Wunused-but-set-variable]
huawei/mm-plugin-huawei.c:183:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:161:24: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:159:24: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
icera/mm-modem-helpers-icera.c:218:25: warning: variable 'first_free' set but not used [-Wunused-but-set-variable]
novatel/mm-common-novatel.c:50:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
Dan Williams
Aleksander Morgado
Aleksander Morgado
Bob Ham
Ben Chan
Dan Williams
Lubomir Rintel