Newer huawei modems, like the E3372, use the following ^GETPORTMODE response
format:
^GETPORTMODE: TYPE: WCDMA: ,pcui:1,modem:2,ncm:3,mass:4,mass_two:5,
This patch updates the parser that looks for the control TTY (pcui) and data TTY
(modem).
https://bugs.freedesktop.org/show_bug.cgi?id=86658
Third revision of Huawei nwtime support. Takes on feedback from the
mailing list including helpers, some basic tests and use of the ^NTCT
command to determine network time support (^NWTIME). Expanded test cases,
more use of g_assert and more logical helper return values/errors.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
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.