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.
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().
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.
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
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
Aleksander Morgado
Dan Williams
Ben Chan
Prathmesh Prabhu
Bjørn Mork
Colin Walters