We don't want to support only 'relative' validity, so don't assume that the
Validity property will always be a uint32 value.
Instead, we define the Validity propery as '(uv)' tuple, where the first value
(a MMSmsValidityType) specifies the type of validity, and the second value is
a variant formatted accordingly to what the validity type specifies (e.g. a
uint32 value if the type is MM_SMS_VALIDITY_TYPE_RELATIVE).
We don't support absolute or enhanced format for validity, but we still need to
properly skip those fields if given.
According to GSM 03.40, they are both always 7 bytes, not just 1.
This is the port to git master of the following commit:
commit 294a91d9f6390d532399be35ddbf6a2b8d136576
Author: Thomas Bechtold <thomasbechtold@jpberlin.de>
Date: Mon Mar 25 14:28:03 2013 +0100
sms-utils: use correct printf modifier for gsize
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.
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.
... or Valgrind will complain:
==4834== Invalid read of size 1
==4834== at 0x43904C: mm_sms_part_new_from_binary_pdu (mm-sms-part.c:783)
==4834== by 0x4382C9: mm_sms_part_new_from_pdu (mm-sms-part.c:485)
==4834== by 0x461D85: sms_pdu_part_list_ready (mm-broadband-modem.c:5004)
==4834== by 0x3161A6CFB6: g_simple_async_result_complete (in /usr/lib64/libgio-2.0.so.0.3200.4)
==4834== by 0x432F82: at_command_parse_response (mm-base-modem-at.c:490)
==4834== by 0x489F96: handle_response (mm-at-serial-port.c:161)
==4834== by 0x486D0A: mm_serial_port_got_response (mm-serial-port.c:588)
==4834== by 0x48758B: data_available (mm-serial-port.c:804)
==4834== by 0x36ADC47694: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
==4834== by 0x36ADC479C7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
==4834== by 0x36ADC47DC1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
==4834== by 0x421398: main (main.c:150)
==4834== Address 0x927e489 is 0 bytes after a block of size 25 alloc'd
==4834== at 0x4A06F18: calloc (vg_replace_malloc.c:566)
==4834== by 0x36ADC4D2C6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3200.4)
==4834== by 0x4844B2: utils_hexstr2bin (mm-utils.c:63)
==4834== by 0x438284: mm_sms_part_new_from_pdu (mm-sms-part.c:476)
==4834== by 0x461D85: sms_pdu_part_list_ready (mm-broadband-modem.c:5004)
==4834== by 0x3161A6CFB6: g_simple_async_result_complete (in /usr/lib64/libgio-2.0.so.0.3200.4)
==4834== by 0x432F82: at_command_parse_response (mm-base-modem-at.c:490)
==4834== by 0x489F96: handle_response (mm-at-serial-port.c:161)
==4834== by 0x486D0A: mm_serial_port_got_response (mm-serial-port.c:588)
==4834== by 0x48758B: data_available (mm-serial-port.c:804)
==4834== by 0x36ADC47694: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
==4834== by 0x36ADC479C7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
If the SMS part is from a multipart message we'll need to create a PDU with a
proper User Data Header.
This patch is based on a previous implementation by:
Roberto Majadas <roberto.majadas@openshine.com>
Aleksander Morgado
Dan Williams
Ben Chan