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.
The logic to setup the generic +CIND indications in the SIM7600E seems
to end up breaking connectivity when in TTY+PPP mode. If we issue the
AT+CMER=3,0,0,1 command, this will end up in the modem not replying a
correct CONNECT response to the ATD command.
Let's disable these +CIND indications completely in the simtech
plugin, as there is even no AT command reference saying those are
supported.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/144
We have deprecated the use of MM_CORE_ERROR_CANCELLED inside the
daemon in favor of using G_IO_ERROR_CANCELLED right away, and so, we
will now register G_IO_ERROR_CANCELLED as the error mapped to the
"Cancelled" error in the ModemManager error domain in DBus.
We therefore avoid sending unknown/unmapped errors via DBus, as in
this case:
$ sudo ./test.sh
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: Connection attempt cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: Connection attempt cancelled'
successfully disconnected all bearers in the modem
error: couldn't connect the modem: 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled'
successfully disconnected all bearers in the modem
The Simple.Disconnect() method handler was totally broken when a
specific bearer path was given, because the user-provided bearer path
was never being stored in the DisconnectionContext struct...
This is an extremely bad error, but it also gives us an indication
that no one is really using this method to disconnect one single
bearer, mainly because we also have the Bearer.Disconnect() method,
which makes more sense. mmcli didn't even allow passing a bearer path
to --simple-disconnect.
