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
If we get an error when telling the SMS list to take the new PDU, the caller is
the one responsible for freeing the part, so avoid doing it twice.
Relevant valgrind log:
==7287== Invalid read of size 8
==7287== at 0x437CE1: mm_sms_part_free (mm-sms-part.c:344)
==7287== by 0x454D11: mm_iface_modem_messaging_take_part (mm-iface-modem-messaging.c:359)
==7287== by 0x461234: cds_received (mm-broadband-modem.c:4626)
==7287== by 0x48A305: parse_unsolicited (mm-at-serial-port.c:256)
==7287== by 0x48723D: parse_response (mm-serial-port.c:731)
==7287== by 0x48759B: data_available (mm-serial-port.c:801)
==7287== by 0x36ADC47694: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x36ADC479C7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x36ADC47DC1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x421398: main (main.c:150)
==7287== Address 0x9840b78 is 24 bytes inside a block of size 104 free'd
==7287== at 0x4A079AE: free (vg_replace_malloc.c:427)
==7287== by 0x36ADC4D37E: g_free (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x36ADC61CCE: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x437D5A: mm_sms_part_free (mm-sms-part.c:351)
==7287== by 0x36ADC449EC: g_list_foreach (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x36ADC44A0A: g_list_free_full (in /usr/lib64/libglib-2.0.so.0.3200.4)
==7287== by 0x43D8A1: finalize (mm-sms.c:1629)
==7287== by 0x36AE8145DA: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.3200.4)
==7287== by 0x43CD52: mm_sms_singlepart_new (mm-sms.c:1376)
==7287== by 0x43E223: take_singlepart (mm-sms-list.c:236)
==7287== by 0x43E60D: mm_sms_list_take_part (mm-sms-list.c:338)
==7287== by 0x454CC7: mm_iface_modem_messaging_take_part (mm-iface-modem-messaging.c:353)
... 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)
Instead of letting the plugins specify a default storage to use, just look at
the supported ones and use the best one.
"MT is preferred over "ME" or "SM", as "MT=ME+SM"
There is no point in specifying a default 'mem1' memory storage, which is used
for reading/listing/deleting, as those are operations that need a specific
'mem1' set each time.
Also, there is no point in specifying separate default 'mem2' and 'mem3' memory
storages, specially because now we allow Sms.Store() to specify a storage.
So, we will now only have a 'default' memory storage, which is applicable for
both 'mem2' and 'mem3' (storing, sending from storage and deleting).
