If a client-initiated disconnection attempt is issued while a
network-initiated disconnection is still pending, the latter may
interfere with the former. Also, when the client-initiated disconnection
attempt fails but the bearer status is reported as 'disconnected', the
pending network-initiated disconnection is not cleared and may result
in an assertion when a connection attempt is issued.
This patch addresses the issue by clearing any pending network-initiated
disconnection before proceeding with a client-initiated disconnection.
The original sysinfoex_parse() in MMBroadbandModemHuawei does not handle
unquoted <sysmode_name> and <submode_name> fields in ^SYSINFOEX responses,
which are sen on some Huawei modems (e.g. E303). This patch moves the
^SYSINFOEX parsing code to mm-modem-helpers-huawei.c, fixes the regex for
handling unquoted strings in ^SYSINFOEX responses, and adds unit tests.
The original sysinfo_parse() in MMBroadbandModemHuawei incorrectly sets
'out_sys_submode_valid' to TRUE even when <sys_submode> is not present
in a ^SYSINFO response. This patch moves the code to
mm-modem-helpers-huawei.c, fixes the regex for parsing ^SYSINFO
responses, and adds unit tests.
This patch modifies mm_3gpp_parse_iccid() to auto-detect if an ICCID
response is character swapped or not by comparsing the major industry
identifier part of the ICCID response to the known value (89) for
telecommunication purposes. This addresses the issue where the same AT
command (e.g. AT^ICCID used by the huawei plugin) does not report ICCID
in a consistent format.
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().
This patch changes MMBroadbandModemHuawei to use ^NDISSTAT unsolicited
messages to handle network-initiated disconnection. As a ^NDISSTAT
unsolicited message is similar to a ^NDISSTATQRY response, the patch
extends the ^NDISSTATQRY parser code to handle both ^NDISSTAT and
^NDISSTATQRY responses.
Don't query udev for the tag every time we recreate a bearer, just do it once.
For some reason, re-querying the same tag after the first time doesn't always
return the proper result.
This patch fixes the following uninitialized variable issues, which was
introduced in the previous commit "huawei: retry connect/disconnect attempt
upon ^NDISSTATQRY? failures" (commit 57c657bd06).
huawei/mm-broadband-bearer-huawei.c:127:9: error: variable 'ipv4_available' is used uninitialized whenever '||' condition is true
[-Werror,-Wsometimes-uninitialized]
if (!response ||
^~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:141:9: note: uninitialized use occurs here
if (ipv4_available && ipv4_connected) {
^~~~~~~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:127:9: note: remove the '||' if its condition is always false
if (!response ||
^~~~~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:115:28: note: initialize the variable 'ipv4_available' to silence this warning
gboolean ipv4_available;
^
= 0
huawei/mm-broadband-bearer-huawei.c:484:9: error: variable 'ipv4_available' is used uninitialized whenever '||' condition is true
[-Werror,-Wsometimes-uninitialized]
if (!response ||
^~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:498:9: note: uninitialized use occurs here
if (ipv4_available && !ipv4_connected) {
^~~~~~~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:484:9: note: remove the '||' if its condition is always false
if (!response ||
^~~~~~~~~~~~
huawei/mm-broadband-bearer-huawei.c:472:28: note: initialize the variable 'ipv4_available' to silence this warning
gboolean ipv4_available;
^
= 0
The Huawei MU736 modem sometimes responds to the ^NDISSTATQRY? query with a
'+CME ERROR: 100' error. This patch works around the issue by ignoring a few
of these error responses in a connect / disconnect attempt. The overall timeout
for the connect/disconnect operation is not affected by this change.
This patch ignores the ^RFSWITCH unsolicited messages in order to avoid
them being mixed with other unsolicited messages. The modem power state
is explicitly determined by the ^RFSWITCH? command, if supported, so we
don't need to depend on the ^RFSWITCH unsolicited messages.
Despite +CSCS? may claim supporting UCS2, Huawei modems always report
the oerator name in ASCII in a +COPS response. This patch addresses that
by always assuming the charset is IRA when parsing the operator name in a
+COPS response.
Newer firmware for Huawei devices will not split the IPv4 and IPv6 info in
different lines for the ^NDISSTATQRY reply; instead they will be included in the
same line. E.g. instead of
^NDISSTATQRY: 1,,,IPV4
^NDISSTATQRY: 0,33,,IPV6
OK
We may have:
^NDISSTATQRY:0,,,"IPV4",0,33,,"IPV6"
Also note the optional spaces after the ':', and that in the new version the
strings are enclosed in double quotes.
https://bugzilla.gnome.org/show_bug.cgi?id=705339
This patch modifies the regular expressions for parsing ^RSSI, ^RSSILVL,
and ^HRSSILVL responses to handle any whitespace that is inserted
between the colon and the RSSI value.
The issue is identified by Dan Williams <dcbw@redhat.com>
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
Newer Huawei modems, like the E3276 or the ME906 won't support ^SYSINFO, and we
should instead use the newer ^SYSINFOEX. By default, use ^SYSINFOEX when
available, as it provides more information than the plain ^SYSINFO.
E.g.:
^SYSINFOEX:2,3,0,1,,3,"WCDMA",41,"HSPA+"
^SYSINFOEX:2,3,1,1,1,3,”WCDMA”,46,”DC-HSPA+”
These messages give us information about the current connection status in the
NDIS interface. We already have other means to know this status, so we just
ignore the unsolicited message for now.
E.g.:
^NDISSTAT: 1,,,"IPV4"
Newer Huawei modems use ^HCSQ to report per-interface signal quality values,
but we don't know yet what each field means for each technology, so just ignore
them for now.
E.g.:
^HCSQ: "GSM", 53
^HCSQ: "WCDMA", 26, 24, 43
^HCSQ: "LTE", 40, 28, 216, 14
We also don't use this message to update current access technology information,
as it is not detailed enough (e.g. WCDMA doesn't specify whether it's plain UMTS
or HSDPA or HSPA+...)
When the serial port buffer gets full of non-AT garbage during port probing,
we were re-scheduling the next probing step, which is completely wrong, as we
then would be processing the same probing task twice. If we get a buffer full,
just cancel the AT probing cancellable, which would cancel not only the possible
AT probings, but also the custom init if there is any.
Also, make sure that the custom_init() of the plugins out there don't return an
error if the GCancellable is cancelled. Cancelling the GCancellable means we
should just stop the custom_init(), and actually sending an error in
custom_init() means that the port should be set as unsupported by the plugin, so
completely different things.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=696695
Plugins which may support QMI ports need to explicitly request QMI probing
in cdc-wdm devices. This should also avoid probing cdc-wdm ports when we know
that the plugin doesn't support them (e.g. with Ericsson MBM devices).
https://bugzilla.gnome.org/show_bug.cgi?id=696701
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
Instead of returning 3 variables in connect_finish(), return a single reference
counted struct. This simplifies how the result is built and passed within a
GSimpleAsyncResult to each _finish() method.
This also simplifies the dialling step in the 3GPP connection sequence, as we
can use the same new type.
We don't want to retry DHCP? on every possible GError reported; specially if the
error is about the port being forced to get closed when the modem gets
unplugged or the like. So just retry on very specific errors reported.
The main cause for retry is really when the modem replies the following:
--> AT^DHCP?
<-- ERROR
Which in our case gets translated to a 'unknown' mobile equipment error. We'll
also consider any kind of mobile equipment error, as the modems may reply a
CME ERROR instead.
