Instead of going through the messaging interface, which just asks
the MMSmsList anyway, just go straight to the list.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Instead of getting it from the MMIfaceModemMessaging when the
SMS is stored. This flattens dependencies between MMBaseSms and
MMIfaceModemMessaging.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This commit moves creation of the MMBaseSms objects out of MMSmsList and up
into MMIfaceModemMessaging (which is already a MMBroadbandModem) and
the MMBroadbandModem subclasses themselves.
This flattens the creation of MMBaseSms objects by passing them down
from the object that creates the SMS parts, rather than having a
convoluted callback scheme relying on MMSmsList and MMBaseSms having
direct knowledge of their owning modem.
The goal is to eventually remove usage of MMBaseModem from MMBaseSms
and MMSmsList so that we can test them more easily.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This helps identify which base sms the message belongs to.
Previous
[modem0/sms-list] found existing multipart SMS object with reference
'126': adding new part
New
[modem0/sms0] found existing multipart SMS object with reference
'126': adding new part
Signed-off-by: Kyle Evans <kvans32@gmail.com>
Messages from different senders can have the same reference.
Stale messages from the same sender can also conflict.
Consider the number of the sender and also the max parts
when assigning parts to a base sms.
Ref 3gpp specification section 9.2.3.24.1
Fixes#757
Signed-off-by: Kyle Evans <kvans32@gmail.com>
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]
When calling g_list_free_full() to free a GList in dispose(), it is
necessary to reset the GList pointer to NULL as dispose() may be called
more than once.
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.
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.
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.
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
Uncompleted multipart SMS will be exported to DBus, where only the "state"
property is valid, so that we allow completely removing those uncompleted
multipart SMS which will never get completed due to one reason or another.
Dan Williams
Kyle Evans
Aleksander Morgado
Lubomir Rintel
Ben Chan
Aleksander Morgado