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.
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
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.
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.
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.
If QMI support was not compiled in, then every net port that wasn't
a QMI port would be force-ignored unless it had the qmi_wwan driver.
Instead, we want to ignore ports with only the qmi_wwan driver.
There are modems out there (e.g. SIM7600E) where we connect a given
CID >1 but once connected, only CID=1 is reported as connected, and
not the one we explicitly attempted to connect. In this situation the
modem is connected successfully, and we're properly ignoring the
disconnection report detected from CGACT? responses, but we're
probably better logging this situation only in debug level, not as
info, because this check is done periodically every 5s...
<debug> [1568649020.333263] (ttyUSB5): --> 'AT+CGDCONT=7,"IP","inet.es"<CR>'
<debug> [1568649020.383517] (ttyUSB5): <-- '<CR><LF>OK<CR><LF>'
<debug> [1568649020.383617] (ttyUSB5) device open count is 3 (open)
<debug> [1568649020.383655] Connection through a plain serial AT port (ttyUSB5)
<debug> [1568649020.383683] (ttyUSB5) device open count is 4 (open)
<debug> [1568649020.383802] (ttyUSB5) device open count is 3 (close)
<debug> [1568649020.383873] (ttyUSB5): --> 'ATD*99***7#<CR>'
<debug> [1568649020.405767] (ttyUSB5): <-- '<CR><LF>CONNECT 115200<CR><LF>'
<debug> [1568649020.405853] [ttyUSB5] Setting flow control: rts-cts
<debug> [1568649020.405878] (ttyUSB5): enabling RTS/CTS flow control
<debug> [1568649020.405897] (ttyUSB5): port attributes not fully set
<debug> [1568649020.405910] (ttyUSB5): flow control settings updated to rts-cts
<debug> [1568649020.405940] (ttyUSB5): port now connected
<debug> [1568649020.405983] Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
<debug> [1568649020.406081] PPP is required for connection, will ignore disconnection reports
<info> [1568649020.406155] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
<info> [1568649020.406361] Simple connect state (8/8): All done
<debug> [1568649020.406461] (ttyUSB5) device open count is 2 (close)
<debug> [1568649020.448483] (net/ppp0): adding device at sysfs path: /sys/devices/virtual/net/ppp0
<debug> [1568649020.448738] (net/ppp0) could not get vendor/product id
<debug> [1568649020.448776] [filter] (net/ppp0) port filtered: virtual device
<debug> [1568649050.395662] (ttyUSB6) device open count is 2 (open)
<debug> [1568649050.395871] (ttyUSB6): --> 'AT+CGACT?<CR>'
<debug> [1568649050.408638] (ttyUSB6): <-- '<CR><LF>+CGACT: 1,1<CR><LF>+CGACT: 2,0<CR><LF>+CGACT: 3,0<CR><LF>+CGACT: 4,0<CR><LF>+CGACT: 5,0<CR><LF>+CGACT: 6,0<CR><LF>+CGACT: 7,0<CR><LF><CR><LF>OK<CR><LF>'
<debug> [1568649050.408803] connection status loaded: disconnected
---> <info> [1568649050.408825] ignoring disconnection report for bearer '/org/freedesktop/ModemManager1/Bearer/0'
<debug> [1568649050.408848] (ttyUSB6) device open count is 1 (close)
<debug> [1568649055.398994] (ttyUSB6) device open count is 2 (open)
<debug> [1568649055.399084] (ttyUSB6): --> 'AT+CGACT?<CR>'
<debug> [1568649055.411489] (ttyUSB6): <-- '<CR><LF>+CGACT: 1,1<CR><LF>+CGACT: 2,0<CR><LF>+CGACT: 3,0<CR><LF>+CGACT: 4,0<CR><LF>+CGACT: 5,0<CR><LF>+CGACT: 6,0<CR><LF>+CGACT: 7,0<CR><LF><CR><LF>OK<CR><LF>'
<debug> [1568649055.411652] connection status loaded: disconnected
---> <info> [1568649055.411674] ignoring disconnection report for bearer '/org/freedesktop/ModemManager1/Bearer/0'
If all CS/PS/EPS report 'denied', we should not report 'unknown' as
consolidated...
<debug> [1568556573.833928] building consolidated registration state: cs 'denied', ps 'denied', eps 'denied' --> 'unknown'
Very much like the MBIM implementation, we will now retry the lock
check if we get a 'SIM not inserted' error reported, because it may
very well be that the device has just been powered up and the SIM is
not fully detected yet.
If the modem interface reports that this is the last attempt to load
the lock status and the modem is still reporting no sim, then, we'll
report a hard error right away. Otherwise, we'll let the generic logic
retry the operation, instead of doing it ourselves.
Aleksander Morgado
Eric Caruso
amol.lad