If the modem is currently disabling, we need to wait to get fully disabled
before starting with the new connection sequence.
If the modem is currently disconnecting, we need to wait to get fully
disconnected before starting with the new connection sequence.
Before the change, the client application loses all new property change
notifications in the interface object:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
After the change, it doesn't:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'initializing' --> 'disabled' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabled' --> 'enabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'enabling' --> 'registered' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'registered' --> 'disabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabling' --> 'disabled' (Reason: User request)
In QMI modems the logic behind supported and current bands is completely
separated in different services (DMS vs NAS). Actually, the list reported by NAS
as current band preferences seems to include more values than the ones reported
by DMS as supported bands (e.g. CDMA bands are reported even if the firmware
image is GSM/HSPA only).
So, just clean up the list of current preferred bands so that no more than those
given as supported is used.
We do need to specify which is the primary port being used for controlling the
modem. This allows us to match the device with an already existing bluetooth
device in NetworkManager.
The interfaces usually retrieve objects (e.g. skeletons) from the Modem object
using g_object_get(), but we didn't make sure that these objects were actually
valid before using them.
This should clean up errors happening when the modem gets unplugged and still
some actions are ongoing.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=685933
Specifying 'none' is really not exclusive. We may want to say that the modem can
either authenticate with a given protocol, or otherwise just try without
authentication.
The reality is that 'none' itself is usually always given in the connection
settings.
Use the new `qmi_utils_set_traces_enabled()' to specify that we want QMI traces
when running with DEBUG logs.
Sync with libqmi:
commit 35dcb4bb6ed2755d968cf97d69faff9ed5f6871f
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Tue Oct 9 13:44:16 2012 +0200
libqmi-glib: message traces compiled always
Message traces have been very useful when debugging issues in the protocol, and
we should avoid requiring a full recompilation in order to get them enabled.
Instead, we provide two new API methods, `qmi_utils_(get|set)_traces_enabled()',
which allow specifying whether traces should be dumped with g_debug() or not.
If we end up allocating too many CIDs without releasing them new allocations
will fail with client-ids-exhausted errors. This usually happens specially
when debugging/developing as you're all the time Ctrl+C-ing the daemon without
rebooting the system.
If the modem is currently being disposed, we may not get a proper GCancellable
when disabling, so try to handle that case in order to avoid warnings like:
GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
#0 0x00007ffff7ab1ba0 in g_log () from /usr/lib64/libglib-2.0.so.0
#1 0x00007ffff7b99784 in g_object_ref () from /usr/lib64/libgobject-2.0.so.0
#2 0x0000000000456c05 in disable (self=0x50d3f0, cancellable=0x0,
callback=<value optimized out>, user_data=<value optimized out>) at
mm-broadband-modem.c:7052
#3 0x0000000000431e69 in handle_enable_auth_ready (self=0x50d3f0,
res=<value optimized out>, ctx=0xa41200) at mm-iface-modem.c:1216
#4 0x00007ffff7e7f447 in g_simple_async_result_complete () from
/usr/lib64/libgio-2.0.so.0
#5 0x0000000000427bc1 in authorize_ready (authp=<value optimized
out>, res=<value optimized out>, simple=0x51d810) at
mm-base-modem.c:1015
#6 0x00007ffff7e7f447 in g_simple_async_result_complete () from
/usr/lib64/libgio-2.0.so.0
#7 0x00007ffff7e7f549 in ?? () from /usr/lib64/libgio-2.0.so.0
#8 0x00007ffff7aaa5c3 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#9 0x00007ffff7aaa940 in ?? () from /usr/lib64/libglib-2.0.so.0
#10 0x00007ffff7aaad7a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#11 0x0000000000417ef2 in main (argc=<value optimized out>,
argv=<value optimized out>) at main.c:150
GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT
(object)' failed
#0 0x00007ffff7ab1ba0 in g_log () from /usr/lib64/libglib-2.0.so.0
#1 0x000000000044af26 in disabling_context_complete_and_free
(ctx=0xa408a0) at mm-broadband-modem.c:6788
#2 0x0000000000431e69 in handle_enable_auth_ready (self=0x50d3f0,
res=<value optimized out>, ctx=0xa41200) at mm-iface-modem.c:1216
#3 0x00007ffff7e7f447 in g_simple_async_result_complete () from
/usr/lib64/libgio-2.0.so.0
#4 0x0000000000427bc1 in authorize_ready (authp=<value optimized
out>, res=<value optimized out>, simple=0x51d810) at
mm-base-modem.c:1015
#5 0x00007ffff7e7f447 in g_simple_async_result_complete () from
/usr/lib64/libgio-2.0.so.0
#6 0x00007ffff7e7f549 in ?? () from /usr/lib64/libgio-2.0.so.0
#7 0x00007ffff7aaa5c3 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#8 0x00007ffff7aaa940 in ?? () from /usr/lib64/libglib-2.0.so.0
#9 0x00007ffff7aaad7a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#10 0x0000000000417ef2 in main (argc=<value optimized out>,
argv=<value optimized out>) at main.c:150
Reported by: Ben Chan <benchan@chromium.org>
Partially fixes: https://bugzilla.gnome.org/show_bug.cgi?id=684693
This is the port to git master of the following commit:
commit 8bd6903c30e52e65a4afbebf85ba59e6c0fada71
Author: Dan Williams <dcbw@redhat.com>
Date: Thu Oct 4 09:34:01 2012 -0500
gsm: fall back to +CSQ if +CIND reports no signal (bgo #636040)
Some devices say they support +CIND signal reporting, but either
actually don't, or they report signal for a non-current access
technology that we don't care about. So if +CIND reports zero
signal, fall back to +CSQ.
Aleksander Morgado
Dan Williams