Implement GPS support on the MU609 and MU090 Huawei modules.
Its highly likely the commands are the same for other Huawei modems
and it just needs to be activated via udev rules that flag the GPS port
with ID_MM_HUAWEI_GPS_PORT=1.
There are a lot of options that can be tweaked on the Huawei GPS setup,
this code just chooses a simple default for unassisted, standalone GPS
operation.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
The MU609 modems from Huawei have a bug (confirmed by Huawei) that causes
the modem to reset if AT^GETPORTMODE is issued.
I have provided and example udev rule I use to disable this command as a
patch, feel free to drop that if its not acceptable. Since I cannot tell
the modem type from within the udev rules this is less specific than my
previous code based patch, but much simpler ;-)
I have two modems that share the same USB ID, however, neither supports the
^GETPORTMODE command (and one of them crashes when it is issued). Perhaps
someone with a Huawei that supports ^GETPORTMODE can check their USB ID's
and see if they clash.
Here is a comment from the Huawei devs:
> We confirmed this is a issue. This is Qualcomm baseband command at Data
> Card. We didn’t delete and block it. We will fix this issue in next FW.
> Thank you very much.
Sign-off-by: David McCullough <david.mccullough@accelecon.com>
With the new 'huawei-cdc-ncm' driver in the kernel, we now may get a
/dev/cdc-wdm AT-capable port exposed by the Huawei device. If so, we must use
this port for NDISDUP dialling in order to get the network interface connected.
The Huawei plugin uses +CFUN=0 to put the modem in low power mode as
+CFUN=4 isn't supported by all Huawei modems. This patch modifies the
plugin to treat CFUN 0 as the 'LOW' power state, which is necessary as
otherwise ModemManager would prevent the modem from transitioning to the
'ON' power state.
This patch simply fixes the following debug message:
from:
<debug> (Huawei) couldn't turn off unsolicited messages insecondary ports: 'Unknown error'
to:
<debug> (Huawei) couldn't turn off unsolicited messages in secondary ports: 'Unknown error'
Adds support for the Huawei E3276 by sending the shortened form of the
AT^NDISDUP command where possible, as the E3276 fails with an '+CME ERROR:
Incorrect parameters' if encoded_auth is set to 0. This behaviour is slightly
different to the E1820 and K4605 (E372) which will happily establish a
connection with encoded_auth set to 0, 1 or 2.
This patch modifies MMBroadbandBearerHuawei such that connect_3gpp
simply reports an error via g_simple_async_report_error_in_idle, without
creating a Connect3gppContext, if no data port is available.
This patch prevents connect_3gpp_context_complete_and_free from calling
'g_object_unref (ctx->data)' when connect_3gpp finds no data port (i.e.
ctx->data is set to NULL).
This patch fixes mm_huawei_parse_prefmode_test to always report an error when
returning NULL, which avoid a potential crash when the caller tries to access
the error.
Some Huawei modems (e.g. E220) may give an empty response for AT^SYSCFG=?, even
if they do support the command. Handle this case by prividing a default fallback
format string when this happens.
On at least the EC168C, various unsolicited responses like RSSILVL,
HRSSILVL, and MODE can include an extra Carriage Return:
^MODE: 2<CR><CR><LF><CR><CR><LF>
^RSSILVL:60<CR><CR><LF><CR><CR><LF>
As soon as we get a match between the current interface being probed, and the
first expected interface to probe, clear the timeout. But this doesn't mean that
this interface being probed will be the correct one, so it may be the case that
we end up expecting a new first interface and probing another one.
With an example probably seen better...
Modem appears with interfaces 2, 3 and 4.
1. We first try to look for interface 0, which is not in the set:
1.1. Probing interfaces 2, 3 and 4 get deferred.
2. First-interface timeout happens because interface 0 doesn't appear, so we
switch to wait for interface 1:
2.1 Probing interfaces 2, 3 and 4 get deferred.
3. First-interface timeout happens because interface 1 doesn't appear, so we
switch to wait for interface 2:
3.1. We get a match on interface 2, which exists. We now remove the
first-interface timeout and start running the init sequence there.
3.2. Probing interfaces 3 and 4 get deferred.
4. Init sequence in interface 2 fails, because it is not an AT port, so we
switch to wait for interface 3:
3.1. We get a match on interface 3, which exists. We do *not* need to remove
now the first-interface timeout because this interface we are testing is
actually the second one which we tried.
So, just check whether the timeout exists or not, and if it exists remove it.
Yeah, this commit just fixes a warning at the end.
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.
Aleksander Morgado
David McCullough
Aleksander Morgado
Ben Chan
Yegor Yefremov
Dan Williams