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.
Instead of just the exact 'Build ID' we now also allow specifying a substring
of the 'PRI info' as ID to select a the new firmware to change to.
If we get multiple matches of the substring in the existing Firmware images
the change is cancelled with error.
Soo... we can now switch firmware images directly from ModemManager, taking care
of completely rebooting the modem directly.
The new image to select needs to be specified by the 'unique-id' currently,
which maps to the 'Build ID' reported in QMI for PRI and MODEM images.
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
The power-down command defined by the plugin will be run *only* after having
checked for current and modem capabilities, as plugins (e.g. Sierra) may have
different commands for that depending on whether they are 3GPP or 3GPP2.
We do not reuse the 'modem_power_down' callback from the disabling sequence, as
some plugins really behave pretty badly with this (e.g. Samsung CFUN=4 may take
up to 30s to complete). So, we let plugins use the power-down command when
disabling but avoid launching it during init.
In order to ease the life for clients listening to the 'state-changed' signal,
the change in the 'state' property in the DBus interface skeleton is flushed
right away, before emitting 'state-changed'. By doing this we make sure that
the 'state-changed' callbacks in the clients are able to see exactly the same
current state in the modem proxy.
The `MMManager' is itself also a `GDBusObjectManagerServer'. If we create this
object after having fully acquired the bus name, the client application in the
other side of the bus could be trying to use the ObjectManager interface before
we actually exported it, which is wrong. Therefore, we need to make sure that
the Manager interfaces are all exported before the name is acquired.
Some modems report "Unknown" as the operator name when failed to obtain
the actual value:
--> 'AT+COPS=3,0;+COPS?<CR>'
<-- '<CR><LF>+COPS: 0,0,"Unknown",0<CR><LF><CR><LF>OK<CR><LF>'
This patch prevents "Unknown" from being treated as a valid operator name.
Don't rely only in the first grabbed port to get VID/PID. Some modems, e.g.
Huawei E367, won't report a proper VID in the cdc-wdm port, which is the first
one probed.
Some modems, e.g. Huawei E367, will probe first the QMI port and for some reason
it doesn't report a proper VID/PID so the Generic plugin is the one finally
accepting that port. When we probe the AT ports afterwards we already got the
Generic plugin as suggestion, and we end up not grabbing the proper primary and
secondary ports as we skipped the AT^GETPORTMODE reply.
So, from now on the Generic plugin is never suggested to other probes; except
for the case where we need the suggestion to finish a probing task which was
'deferred until suggested'.
Also, the device-level plugin can now be overwritten, if and only if, the
previously set plugin was the Generic one.
Some devices, e.g. ZTE MF820D, seem to prefix the `AT+CGMM?' response with the
`+CGMM:' string, resulting in the following model string being loaded:
model: '+CGMM: "MF820D"'
Avoid this by:
1) Removing the expected prefixes.
2) Unquoting the resulting string.
Reported by: Marius Kotsbak <marius.kotsbak@gmail.com>
When a user creates an SMS object, we will expose all its properties in DBus
properly, but we will not create the internal list of SMS parts.
The list of SMS parts will be created when the SMS is stored or sent, whatever
comes first. When the message is sent and it was previously stored, the list of
parts is not re-created.
If the message requires multiple parts, the multipart reference is computed as
follows:
* If the SMS was not stored and is being sent, we just use a random number.
* If the SMS is being stored, we will use a multipart reference which is not
being used already in another SMS to the same destination.
When receiving an SMS, if the encoding is either GSM7 or UCS2, we will treat the
contents of the SMS as text; and if the encoding is either 8BIT or unknown, we
will just dump the contents of the SMS as data.
When creating an SMS, the user is not allowed to give both text and data, only
one can be given. We will use by default 8BIT when data is given, and guess the
best encoding if text is given.
Note that it's still possible to have SMS with neither text nor data, as in
delivery status reports.
This commit also handles the split of the input data in order to make it fit
into singlepart or multipart messages.
We will look for the part being notified in the CMTI indication directly in the
list of processed parts; and if we have it there already we won't re-process it.
Still, we may get several CMTI indications for the same part one after the
other, so it may still happen that the second CMTI comes *before* we have parsed
and created the part in the SMS list. For that case, the SMS list will reject
taking the part if there is already a part with the same storage+index already
processed.
This fix removes the `known_sms_parts' hash table, which was being handled
incorrectly.
This should fix https://bugzilla.gnome.org/show_bug.cgi?id=675175
Aleksander Morgado
Ben Chan