It was observed that sporadically it may take more than 5 seconds for modem to
respond to AT#REBOOT. Increase the timeout on AT command to not report
unnecessary errors to the user.
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'
This new flag allows users of the API to know whether general purpose
voice calls are allowed or otherwise only voice calls to the
registered emergency numbers should be performed.
ModemManager won't really do any distinction between emergency and
non-emergency calls at this point, this flag is just an early
indication for the user of the API that no normal voice call should be
attempted.
Instead of using the firmware step as fallback when the modem goes
into failed or locked state, use an independent step in the
initialization state machine, just to make it clearer.
We only allow one single Simple.Connect() attempt at a time. If more
than one arrives, the second and next ones will be forbidden.
The ongoing connection attempt can now always be cancelled via
Simple.Disconnect(), not only *after* the bearer object connection has
started. i.e. if Simple.Disconnect() is called e.g. while waiting to
be registered, we would also be cancelled properly.
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
The SIM7600E ends up emitting these URCs with too many <CR>s, and the
generic +CRING handler doesn't catch them, interfering with other
actions, e.g.:
$ sudo mmcli --call 1 --accept
error: couldn't accept the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't accept the call: Unhandled response '+CRING: VOICE
+CRING: VOICE''
Just processing and parsing them for now, so that they don't interfere
with other commands:
$ sudo mmcli --call 1 --accept
error: couldn't accept the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't accept the call: Unhandled response '
VOICE CALL: BEGIN''
If the full list reporting includes calls in terminated state (e.g. on
modems managed by the Simtech plugin), then ignore those no longer
known to us, because it just means that they have already been
processed.
<debug> [1571060859.227759] (ttyUSB2): <-- '<CR><LF>+CLCC: 1,0,6,0,0,"639335936",129<CR><LF>'
<debug> [1571060859.227890] Reported 1 ongoing calls
<debug> [1571060859.227913] call at index 1: direction outgoing, state terminated, number 639335936
<debug> [1571060859.227946] call info matched (matched direction/state no, matched index yes, matched terminated no) with call at '/org/freedesktop/ModemManager1/Call/1'
<debug> [1571060859.227963] state updated: terminated
<info> [1571060859.227978] Call state changed: dialing -> terminated (unknown)
<debug> [1571060859.228173] (ttyUSB3): <-- '<CR><LF>+CLCC: 1,0,6,0,0,"639335936",129<CR><LF>'
<debug> [1571060859.228234] Reported 1 ongoing calls
<debug> [1571060859.228251] call at index 1: direction outgoing, state terminated, number 639335936
<warn> [1571060859.228274] unexpected outgoing call to number '639335936' report2ed in call list: state terminated
So that we can avoid gtk-doc complaining about them:
2019-10-14 10:46:59,583:common.py:ParseEnumDeclaration:427:WARNING:Cannot parse enumeration member:
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_FIRST is missing in source code comment block.
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_LAST is missing in source code comment block.
The log message would display a value based on combining the
notification flags with a CID, which doesn't make sense. Test
against the flag for this notification instead.
We will explicitly query for +AUTOCSQ and +CNSMOD support before
trying to enable them.
If +AUTOCSQ is supported and correctly enabled, we'll request signal
quality polling to be disabled.
If +CNSMOD is supported and correctly enabled, we'll request access
technology polling to be disabled.
Same as with the signal quality polling, we may want to disable
explicitly the access technology polling if we can rely on plugin
specific URCs for this purpose.
E.g. if we have a specific command to enable the signal quality URCs,
we should only disable polling if the command is supported by the
specific modem and the command succeeds. If unsupported or fails, we
shouldn't disable the polling.
The +AUTOCSQ setup enables automatic signal quality reporting via +CSQ
URCs, which unfortunately have the same format as the +CSQ command
responses.
Therefore, we need to subclass load_signal_quality() explicitly in
order to ignore those cases where the response to the +CSQ command is
received empty (already processed as a URC).
If we're loading signal quality or access technology, skip reporting
any error message if the specific error received is 'in-progress'.
Plugins will use this error when they cannot process the response to
the operation, e.g. if it was already consumed by a URC handler.
Aleksander Morgado
Krzysztof Drobinski
Eric Caruso