We should not assume that a manual registration request to a given
operator is successful if the modem is already registered in that
operator, because if the registration was due to an automatic process,
we cannot make sure the modem won't roam to a different network.
We should only assume that a manual registration is not needed to be
relaunched if the modem is already registered in the requested network
AND if the registration process was manual (i.e. we asked the modem to
lock into a given network).
If the modem (e.g. u-blox LARA) returns a "Not supported" error when
attempting to run +COPS=1,2,<mccmnc> with the MCCMNC encoded in ASCII
(and current charset is different, e.g. UCS2), then attempt to re-run
the same command with the MCCMNC encoded in the explicit current
charset.
<debug> (ttyACM0): --> 'AT+COPS=1,2,"21404"<CR>'
<debug> (ttyACM0): <-- '<CR><LF>+CME ERROR: 4<CR><LF>'
<debug> Got failure code 4: Operation not supported
<debug> (ttyACM0): --> 'AT+COPS=1,2,"00320031003400300034"<CR>'
<debug> (ttyACM0): <-- '<CR><LF>+CME ERROR: 111<CR><LF>
If the charset selected via CSCS is UCS2, the modem may decide to
return all the strings in the +COPS=? response in UCS2:
<debug> (ttyACM0): --> 'AT+COPS=?<CR>'
<debug> (ttyACM0): <-- '<CR><LF>+COPS: (2,"004D006F007600690073007400610072","004D006F007600690073007400610072","00320031003400300037",7)
<debug> Found network '00320031003400300037' ('004D006F007600690073007400610072','004D006F007600690073007400610072'); availability: current, access tech: lte
If the Simple.Connect() operation fails before the bearer connection
process starts (e.g. during the previous SIM-PIN checks or explicit
registration attempt), the ongoing connect cancellable is not being
properly cleared, and this would prevent additional new connection
attempts unless an explicit Simple.Disconnect() is called.
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
$ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet"
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress'
Fix this, by making sure the ongoing connect cancellable is always
cleared when completing the DBus method invocation that created it.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/169
Defining the new error codes in the headers is not enough, we also
need to add support in the error helpers in order to create proper
GErrors with the expected error codes.
We don't want the connection status checks to interfere with the
disconnection logic, e.g. if they're both using the same TTY for both
things.
E.g. the CGACT? from the conncheck gets in the way of the
disconnection logic:
<debug> [1576037519.710684] Flashing data port (ttyUSB1)...
<debug> [1576037519.710740] (ttyUSB1): port attributes not fully set
<debug> [1576037520.287636] (ttyUSB1) device open count is 3 (open)
<debug> [1576037520.287804] (ttyUSB1): --> 'AT+CGACT?<CR>'
<debug> [1576037520.711067] (ttyUSB1) device open count is 2 (close)
<debug> [1576037520.711127] (ttyUSB1): running init sequence...
<debug> [1576037520.711231] PDP disconnection already sent
<debug> [1576037520.711263] Disconnected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Instead, fully skip all conncheck and stat updates as long as the
modem is not connected. The actual conncheck and stat update timeouts
will be removed once completely disconnected, as it was before.
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'
When we try to disconnect a bearer and the bearer is already
disconnected (e.g. after a cancelled connection attempt), avoid reporting
that as an error:
<warn> [1575287560.433398] Error disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0': 'Couldn't disconnect QMI bearer: this bearer is not connected'. Will assume disconnected anyway.
If a WDS indication is received telling us that the modem is no longer
connected, abort the ongoing connection attempt right away with an
error and cleanup all allocated clients (implicitly disconnecting them
if required)..
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/155
If the bearer is using a QMI port that is not the primary one, we need
to explicitly open it during the connection attempt. Keep track of
that, and make sure we close it during normal disconnection or if the
connection attempt fails.
If we blindly try to use QMI over MBIM on devices that don't support
it, the logic works ok but it's very slow, given that the QMI device
open operation has several internal retries, and all those end up
timing out.
Avoid that lost time by checking the list of services supported by the
MBIM modem, and if the QMI over MBIM service is not listed, we'll
avoid trying to open the QMI device right away.
Until now we had only a 2500ms timeout initialized since the first
port was exposed until we decided we were ready to consider all ports
notified by the kernel.
With this new logic, we add an additional condition: even if the
2500ms initial timeout has elapsed already, we leave an additional
1500ms since the last port addition for new ports to appear.
This new logic is useful when relying on the ReportKernelEvent() DBus
method, as it is the user the one responsible for reporting the kernel
events instead of udev. Now, the user is not forced to make sure all
ports are exposed in 2500ms; instead, we also allow ports to be
reported in more than 2500ms as long as the time between port
additions reported is less than 1500ms.
Note that this does not mean that the whole probing time will now
always be 4000ms. On well behaved systems (like when based on udev)
this new 'extra' probing timeout may expire long before the 'min'
probing timeout we already had as well.
E.g. in this setup, the reporting of the NET port was done 1100ms
later than the last ttyUSB3, and that was already too late as the
original 2500ms threshold had already expired.
[1573536994.593874] (tty/ttyUSB0): first port in device /sys/devices/platform/ehci-platform/usb1/1-1
[1573536994.596659] [plugin manager] task 1: port grabbed: ttyUSB0
[1573536995.093579] (tty/ttyUSB1): additional port in device /sys/devices/platform/ehci-platform/usb1/1-1
[1573536995.094172] [plugin manager] task 1: port grabbed: ttyUSB1
[1573536995.603206] (tty/ttyUSB2): additional port in device /sys/devices/platform/ehci-platform/usb1/1-1
[1573536995.603822] [plugin manager] task 1: port grabbed: ttyUSB2
[1573536996.111564] (tty/ttyUSB3): additional port in device /sys/devices/platform/ehci-platform/usb1/1-1
[1573536996.112257] [plugin manager] task 1: port grabbed: ttyUSB3
[1573536996.814816] [device /sys/devices/platform/ehci-platform/usb1/1-1] creating modem with plugin 'Quectel' and '4' ports
[1573536997.265820] (net/wwan0): additional port in device /sys/devices/platform/ehci-platform/usb1/1-1
[1573536997.296935] (usbmisc/cdc-wdm0): additional port in device /sys/devices/platform/ehci-platform/usb1/1-1
If we know that the LTE attach status/configuration CIDs in the Basic
Connect Extensions service are unsupported, don't even try to use
them, so that we avoid timeouts in the requests.
[11642]: <debug> [1573665255.321490] Couldn't reload current power state: QMI operation failed: Transaction timed out
[11642]: <debug> [1573665255.321697] No need to change power state: already in 'on' power state
[11642]: <debug> [1573665255.330864] Modem (Quectel) '/sys/devices/platform/ehci-platform/usb1/1-1' completely disposed
**
ERROR:mm-iface-modem-simple.c:44:private_free: assertion failed: (!priv->ongoing_connect)
If the modem goes away in the middle of a connection attempt, there's
no explicit connection cancellation performed, we just cleanup the
modem object. In this case, the ongoing attempt cancellable will still
exist, so just clean it up as well.
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.
Aleksander Morgado
Amol Lad