Originally developed by:
Prathmesh Prabhu <pprabhu@chromium.org>
Ben Chan <benchan@chromium.org>
Huawei MU736 prematurely fires a ^NDISSTAT unsolicited message upon a
network-initiated disconnection. The modem can go into a bad state if a
reconnect attempt happens before the disconnection completes. This patch works
around the issue by delaying the reporting of the disconnection.
Originally developed by:
Ben Chan <benchan@chromium.org>
This patch replaces mm_bearer_report_disconnection() with a more generic
mm_bearer_report_connection_status(), which allows reporting any
connection status of a bearer. This further allows getting rid of those
custom report_connection_status functions in plugic specific bearer
subclasses.
Note that while plugin-specific implementations can receive multiple
'MMBearerConnectionStatus' values, the generic implementation is only allowed
to receive DISCONNECTED. Plugins need to make sure that they process all the
other status values, and only report DISCONNECTED to the parent when required.
MBM:
The MBM bearer implementation of report_connection_status() expects either
CONNECTED or DISCONNECTED. If any of these is received and there is an ongoing
connection attempt, the corresponding operation will be completed. If there is
no connection attempt, we will just handle the DISCONNECTED state, calling the
parent method to notify that the modem got network-disconnected.
Icera:
The Icera bearer implementation of report_connection_status() expects either
CONNECTED, CONNECT FAILED or DISCONNECTED. If any of these is received and
there is an ongoing connection or disconnection attempt, the corresponding
operation will be completed. If there is no connection or disconnection
attempt, we will just handle the CONNECT FAILED and DISCONNECTED states,
calling the parent method (always with DISCONNECTED) to notify that the modem
got network-disconnected.
Option/HSO:
The Option/HSO bearer implementation of report_connection_status() expects
either CONNECTED, CONNECTION FAILED or DISCONNECTED. If any of these is
received and there is an ongoing connection or disconnection attempt, the
corresponding operation will be completed. If there is no connection or
disconnection attempt, we will just handle the CONNECTION FAILED and
DISCONNECTED states, calling the parent method (always with DISCONNECTED) to
notify that the modem got network-disconnected.
Huawei:
The Huawei bearer implementation of report_connection_status() expects either
CONNECTED or DISCONNECTED. These messages are not used to process pending
connection or disconnection attempts; so if they are received while one of
these is on-going, it will just be ignored. CONNECTED reports are also
ignored, so we will just handle the DISCONNECTED state, calling the parent
method to notify that the modem got network-disconnected.
Altair-LTE:
The Altair-LTE bearers will only report DISCONNECTED on network-disconnected
cases. There is no custom report_connection_status().
Novatel-LTE:
The Novatel-LTE bearers will only report DISCONNECTED on network-disconnected
cases. There is no custom report_connection_status().
When we get an internal error while checking the lock status, tell the upper
layers that we can retry the check. It's been observed that this internal error
may be issued not only when e.g. there is no SIM, but also when the SIM is not
yet fully ready.
The new internal_load_unlock_required() method will take care of running the
subclassed load_unlock_required(), if available, and also retry the check up
to 6 times.
This method will be used both by the standard unlock required check and by the
check within the current capabilities loading for multimode devices.
This patch fixes an assertion failure 'ctx->fatal_error == NULL' in
initialization_context_complete_and_free(), which happens if
'fatal_error' of the initialization context is set during the modem
interface initialization and the initialization is later cancelled.
This patch changes MMBroadbandModem to report an
org.freedesktop.ModemManager1.Error.Core.InProgress error, instead of an
org.freedesktop.ModemManager1.Error.Core.WrongState error, when one
tries to initialize a modem that is already being initialized, or to
enable a modem that is already being enabled.
The Huawei MU736 supports CIND? but not for signal quality reporting:
AT+CIND=?
+CIND : ("call",(0,1)), ("message",(0,1)), ("roam",(0,1))
OK
AT+CIND?
+CIND:0,0,0
OK
Which ended up with the following during execution:
ModemManager[3044]: (ttyUSB1) Could not parse CIND signal quality results;
signal index (255) outside received range (0-3)
Just avoid this, and make CIND? be used for signal quality retrieval only if
(1) CIND? is actually supported and (2) CIND? reports signal quality
information.
Just add the messages with debug level, so that they don't get reported at
syslog. Having this kind of warnings in syslog is not useful, specially because
we wouldn't know which was the specific command that issued the warning. Errors
due to critical issues will anyway be reported in syslog in some way or another.
This patch adds an 'enable' flag in MMAtUnsolicitedMsgHandler and
mm_at_serial_port_enable_disable_unsolicited_msg_handler() to allow
enabling and disabling of unsolicited message handlers. The enable flag
is set to TRUE by mm_at_serial_port_add_unsolicited_msg_handler().
E.g. in the GetSignalStrength output we get EV-DO-only TLVs, even if EV-DO is
not the current access technology, what ends up generating the following:
$ sudo mmcli -m 0 --signal-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
Refresh rate: '5' seconds
-------------------------
EV-DO | RSSI: '0.00' dBm
| EcIo: '0.00' dBm
| SINR: '9.00' dBm
| Io: '-106.00' dB
-------------------------
UMTS | RSSI: '94.00' dBm
| EcIo: '-6.00' dBm
Instead, we will now assume that the RSSI list always contains the valid access
technologies being reported, and use that list to decide whether we process some
of the per-technology TLVs. We now end up getting:
$ sudo mmcli -m 0 --signal-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
Refresh rate: '5' seconds
-------------------------
UMTS | RSSI: '94.00' dBm
| EcIo: '-8.00' dBm
The format of CREG/CGREG/CEREG responses is not very precisely defined
in or strictly enforced by the 3GPP specifications. That leads to the
fact that some modems put leading zeros in integer type fields (e.g.
<n>, <stat>, <AcT>), and not all modems put double quotes around string
type fields (e.g. <lac>, <ci>) in those C*REG responses.
For example, 0001 can be a valid value for both <stat> and <lac>. The
original C*REG parsing code in ModemManager could potentially interpret
'+CREG: <stat>,<lac>,<ci>,<AcT>' as '+CREG: <n>,<stat>,<lac>,<ci>'. This
patch addresses this issue by refining the regular expressions returned
by mm_3gpp_creg_regex_get() with the following assumptions:
1. If a modem puts leading zeros in integer type fields, it puts double
quotes around string type fields.
2. If a modem omits double quotes around string type fields, it does not
put leading zeros in integer type fields.
When we're exposing not-yet-completed multipart messages, we need to provide a
correct value for the validity property, or gdbus may crash, see e.g.:
https://bugzilla.gnome.org/show_bug.cgi?id=704319
This patch fixes the following incorrect conversions from double to gint32:
mm-broadband-modem-qmi.c:4785:27: error: implicit conversion from 'double' to 'gint32' (aka 'int')
changes value from 2.225073858507201E-308 to 0 [-Werror,-Wliteral-conversion]
gint32 bs_longitude = MM_LOCATION_LONGITUDE_UNKNOWN;
~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:4786:26: error: implicit conversion from 'double' to 'gint32' (aka 'int')
changes value from 2.225073858507201E-308 to 0 [-Werror,-Wliteral-conversion]
gint32 bs_latitude = MM_LOCATION_LATITUDE_UNKNOWN;
~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
This patch fixes the following enumeration type mismatches:
mm-modem-helpers-qmi.c:980:12: error: implicit conversion from
enumeration type 'QmiNasRatModePreference' to different
enumeration type 'QmiNasRadioTechnologyPreference' [-Werror,-Wenum-conversion]
return qmi;
~~~~~~ ^~~
mm-modem-helpers-qmi.c:1082:12: error: implicit conversion from
enumeration type 'MMModemMode' to different
enumeration type 'QmiNasGsmWcdmaAcquisitionOrderPreference' [-Werror,-Wenum-conversion]
return MM_MODEM_MODE_NONE;
~~~~~~ ^~~~~~~~~~~~~~~~~~
mm-modem-helpers-qmi.c:1096:16: error: implicit conversion from
enumeration type 'QmiNasRegistrationState' to different
enumeration type 'MMModem3gppRegistrationState' [-Werror,-Wenum-conversion]
return QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED;
~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prints out a warning if ioctl(TIOCSSERIAL) fails to set closing_wait to
none. This helps debug issues when a serial driver does not support or
properly handle closing_wait, which may cause closing of the serial port
to block.
Icera-based Nokia modems may reply correctly to the Icera probing only in some
AT ports, not in all. In order to handle this situation we override the final
plugin selected to be the Icera-based one if we find that the mismatched plugins
have the 'icera-allowed' and 'icera-forbidden' filters.
https://bugzilla.gnome.org/show_bug.cgi?id=703022
Aleksander Morgado
Arun Raghavan
Ben Chan
Dan Williams