Keeps build with GCC 8 happy.
mm-base-call.c:758:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-call.c:822:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-base-sms.c:908:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
mm-sms-list.c:331:25: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
mm-iface-modem-messaging.c:1210:21: warning: variable 'storage_ctx' set but not used [-Wunused-but-set-variable]
huawei/mm-plugin-huawei.c:183:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:161:24: warning: variable 'response' set but not used [-Wunused-but-set-variable]
ublox/mm-plugin-ublox.c:159:24: warning: variable 'ctx' set but not used [-Wunused-but-set-variable]
icera/mm-modem-helpers-icera.c:218:25: warning: variable 'first_free' set but not used [-Wunused-but-set-variable]
novatel/mm-common-novatel.c:50:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
A default implementation to monitor the ongoing connection is provided in the
generic MMBroadbandModem, based on AT+CGACT? to check whether the PDP context
of the connection (identified by the cached cid) is active or not.
This commit also disables the connection monitoring logic in those plugins that
have custom connection methods.
If the modem thinks a PDP context is already active it'll return
583 errors from IPDPCFG and IPDPACT until the context is
deactivated. Deactivation was previously done after authentication,
but needs to be done before any part of the connect process to
ensure the PDP context is inactive.
The previous approach worked only if the context was being
deactivated already (which can take a bit of time) because it would
be deactivated after a few seconds and the connect could continue.
This approach works for more cases (like a MM crash and restart
while the modem is connected).
Split out the %IPDPADDR parsing into a helper and add testcases for it,
and add support for IPv6 handling. If the returned IPv6 is link-local,
the address should be assigned to the interface and SLAAC performed to
retrieve the actual IPv6 prefix and RDNSS/DNSSD information.
Subclasses may need to know which IP families were used for the setup
so they can return the correct IP configuration. We can't just use
the MMBearer default_ip_family becuase that isn't the family that
was actually used during the connection.
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().
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.
The GetNetworkTime() response is defined to be an ISO8601 string, which
is in turn defined to be in local time. Make sure that's reflected in
the documentation, and append the timezone offset to UTC where we have
it.
Oddly, Icera devices return their time info in UTC with an offset to
the local timezone, so we have to jump through some hoops there to
convert the response to localtime based on the reported offset.
Some additional fixes by Aleksander Morgado <aleksander@lanedo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=697372
Icera devices include bands that the modem doesn't support in
the %IPBM=? list, so the plugin sets the band to its current
enabled/disabled value to test whether that band is supported.
There were two problems with this approach:
1) Setting an already-enabled band to be enabled apparently
isn't a NOP; it might take more than the 3 seconds given, and
if the response comes after 3 seconds, this greatly confuses
ModemManager because the AT command/reply sequence is now
messed up. So increase the timeout to 10 seconds.
2) Why bother checking bands that are already enabled anyway?
We already know they are supported, so just don't check those
bands at all. This requires some parkour because we use the
parsed band array from %IPBM=? to track whether bands are
enabled/disabled by indexing into the array, so instead just
use two separate arrays. This actually makes the fix for #1
un-needed (because we never enable any bands) but it's good
to have #1 anyway.
+CME ERROR: 3 (Not Allowed) means airplane mode, at least for the
Samsung Yxxxx devices that I've got. And if we get this error
on any other devices, chances are they'll fail to power up too.
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.
If the primary port is gone (e.g. when going to sleep) and we are just in the
middle of a connection attempt, we won't be able to receive any unsolicited
message regarding the status of the attempt. So, if we detect that the port is
forced to get closed, we'll just treat it as a connection failure.
http://code.google.com/p/chromium-os/issues/detail?id=35391
The logic gets completely stuck when this happens:
Stack trace below:
#0 0x77661424 in __kernel_vsyscall ()
#1 0x77337c3c in pthread_cond_wait ()
#2 0x773cebaa in g_cond_wait () from /usr/lib/libglib-2.0.so.0
#3 0x774c03cc in g_cancellable_disconnect () from /usr/lib/libgio-2.0.so.0
#4 0x76955d36 in connect_cancelled_cb (cancellable=0x78e055a0, self=0x78e0b590)
#5 0x77460982 in g_cclosure_marshal_VOID__VOIDv () from /usr/lib/libgobject-2.0.so.0
#6 0x7745ed8a in ?? () from /usr/lib/libgobject-2.0.so.0
#7 0x77478435 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#8 0x77478eb3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#9 0x774c01eb in g_cancellable_cancel () from /usr/lib/libgio-2.0.so.0
#10 0x776a0eab in mm_bearer_disconnect (self=0x78e0b590, callback=0x776c5980 <disconnect_ready>,
#11 0x776c57de in disconnect_next_bearer (ctx=0x78e12870) at mm-iface-modem-simple.c:898
#12 0x776c58d2 in disconnect_auth_ready (self=0x78df3048, res=0x78e06210, ctx=0x78e12870)
#13 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#14 0x776a8c4e in authorize_ready (authp=0x78db68d0, res=0x76801638, simple=0x78e06210)
#15 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#16 0x774fee3e in ?? () from /usr/lib/libgio-2.0.so.0
#17 0x7738a7a2 in ?? () from /usr/lib/libglib-2.0.so.0
#18 0x7738ce83 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#19 0x7738d248 in ?? () from /usr/lib/libglib-2.0.so.0
#20 0x7738d6eb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#21 0x77696a7d in main (argc=2, argv=0x7fbb1f04) at main.c:158
http://code.google.com/p/chromium-os/issues/detail?id=36448
We will not report 'CS' as a supported mode every time '2G' is supported. This
actually was forcing all plugins to handle a 'CS' fallback when they didn't have
CS-specific mode setup. So, to simplify things, we will only report 'CS' as
supported for those plugins which actually allow to select 'CS' mode (e.g. the
'wavecom' plugin).
If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
Tries to fix https://bugzilla.gnome.org/show_bug.cgi?id=685578
