Age | Commit message (Collapse) | Author |
|
This patch fixes own_enable_unsolicited_events_ready() to use
mm_base_modem_at_command_full_finish(), instead of
mm_base_modem_at_sequence_full_finish(), as the %STATCM=1 command is
issued via mm_base_modem_at_command_full().
|
|
|
|
See commit c79d266e627242b22a5e146ab157e34135e7a36a.
If the rules to tag specific USB interface numbers only apply on the PID, we'll
end up seeing that if the port has a parent with another PID, and that other
PID also has a rule, port will get tagged multiple times.
|
|
For HW version A5 and possibly later, which are based on MediaTek
chipsets instead of Qualcomm ones.
|
|
Signed-off-by: Quentin.Li <snowmanli88@gmail.com>
|
|
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.
|
|
This device ID is used in a Lenovo Thinkpad T430.
Link: http://bugs.debian.org/705942
Reported-by: Etienne Bagnoud <etienne.bagnoud@irovision.ch>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
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 broke gnome-control-center in gnome-ostree. It should be
included in the C file where stuff from the private header is
actually used.
|
|
g_async_result_get_source_object() returns a full reference, which needs to get
unref-ed when no longer used.
|
|
Use AT^ICCID if possible to read the ICCID.
|
|
|
|
Reported by Arman Uguray <armansito@google.com>
|
|
Reported by Arman Uguray <armansito@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We were already requiring some features from 1.5.0 (dev version), so depend
on the stable 1.6.0 now that it's out.
|
|
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 57c657bd066366db6892ac2a8adfec2ca209ccbe).
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.
|
|
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
Also modify the QMI-specific implementation to act as a state machine, as we'll
add more steps afterwards.
|