Avoids this kind of issues:
[mm-sms-list.c:334] mm_sms_list_take_part(): SMS part at 'me/0' is from a singlepart SMS
[mm-iface-modem-messaging.c:475] sms_added(): Added received SMS at '/org/freedesktop/ModemManager1/SMS/31'
[mm-broadband-modem.c:4791] sms_pdu_part_list_ready(): Error parsing PDU (1): PDU too short (2): 41 < 79
GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: PDU too short (3): 28 < (210 + 14), user data length: '203'
[mm-broadband-modem.c:4791] sms_pdu_part_list_ready(): Error parsing PDU (2): PDU too short (3): 28 < (210 + 14), user data length: '203'
Sometimes the 'Mode Preference' TLV in the SSP response will have incorrect
values. The following log is for a Gobi3k modem which is *only* GMS/UMTS.
ModemManager[13415]: [/dev/cdc-wdm0] Received message...
>>>>>> QMUX:
>>>>>> length = 44
>>>>>> flags = 0x80
>>>>>> service = "nas"
>>>>>> client = 2
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 32
>>>>>> message = "Get System Selection Preference" (0x0034)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = "Emergency mode" (0x10)
>>>>>> length = 1
>>>>>> value = 00
>>>>>> translated = 0
>>>>>> TLV:
>>>>>> type = "Mode Preference" (0x11)
>>>>>> length = 2
>>>>>> value = 0F:00
>>>>>> translated = 15
>>>>>> TLV:
>>>>>> type = "Band Preference" (0x12)
>>>>>> length = 8
>>>>>> value = FF:FF:FF:3F:FF:FF:FF:FF
>>>>>> translated = 18446744070488326143
>>>>>> TLV:
>>>>>> type = "Roaming Preference" (0x14)
>>>>>> length = 2
>>>>>> value = FF:00
>>>>>> translated = 255
Instead of setting to '1' only the bits related to GSM/UMTS in the "Mode
Preference" TLV, the modem sets all the bits it knows of to '1', including the
CDMA/EVDO ones. It is not easy to detect this properly, because the modem didn't
set to '1' the bits it didn't know of (e.g. LTE or TD-SCDMA), so we *cannot*
assume that 0x000F actually means 'unknown'.
So, we now will pass these returned values through the "DMS Get Capabilities"
filter, as we did for the Technology Preference result. The final reported
current capabilities will be either:
* The intersection between the capabilities loaded by "NAS Get System Selection
Preference" and "DMS Get Capabilities" or,
* The intersection between the capabilities loaded by "NAS Get Technology
Preference" and "DMS Get Capabilities".
For 'modem' (not 'current') capabilities, we still rely only on "DMS Get
Capabilities".
Modem plugins may set the 'modem' property before the 'config' property when
creating a bearer. set_signal_handlers() should thus be called after both
properties are set such that modem_{3gpp,cdma}_registration_state_changed
checks roaming allowance correctly when launching a connection.
Based on a draft patch by:
Ben Chan <benchan@chromium.org>
ModemManager configure script currenty requires glib 2.30.2 or later,
bud g_variant_new_fixed_array requires at least glib 2.32. To maintain
the compatibility with glib 2.30, this patch modifies the code to use
g_variant_new_from_data instead of g_variant_new_fixed_array.
For those who don't care about the QMI support through libqmi-glib, or if you're
stuck with glib 2.30 (libqmi-glib requires 2.32), this configure switch allows
disabling the QMI support completely.
The logic to detect cdc-wdm ports is still in place, but the QMI probing is
never launched at them. Also, all QMI-related objects won't be compiled.
Modems have a maximum of bearers allowed to be connected at a time, number which
is given by the number of available ports that may be used for data connections.
When Simple.Connect() tries to launch a connection, it will try to find first an
existing bearer with the required parameters (e.g. APN, IP type). If such bearer
is found, it will just use it. If no such bearer is found, it will try to create
one. When trying to create one, if there is no more room for bearers in the
modem, we will remove the first disconnected bearer that we find, if any, before
trying to create the new one. This logic now makes sure that no connected bearer
gets removed in order to create a new one, and also that only one existing gets
removed if possible (not every bearer as we did previously).
Further logic to connect multiple bearers at a time cannot be done using the
Simple interface.
Huawei modems will probe interface 0 always first; if we try to probe another
interface meanwhile the supports check will give us a MM_CORE_ERROR_RETRY error,
indicating that we need to defer the probing of the port.
AT!SELRAT=?
!SELRAT: Index, Name
00, Automatic
01, UMTS 3G Only
02, GSM 2G Only
03, Automatic
04, Automatic
05, GSM and UMTS Only
06, LTE Only
07, GSM, UMTS, LTE
When the modem gets unplugged, or system gone into suspend, we start losing the
modem ports one by one. When the last is lost, we trigger the disposal of the
modem (we call g_object_run_dispose() and then we call the main-reference
unref()). So, if we end up losing all ports while the connection sequence was
being run, we would end up in this situation, where we try to disconnect the
bearers (the bearer and modem objects are still valid, as we have references
around, but the list of bearers won't be available any more in the modem object
as it was cleared in the modem dispose().
Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 )
0x7f5cdbd5cda0 [ModemManager] - mm-bearer-list.c:163] mm_bearer_list_foreach
0x7f5cdbd6a4bd [ModemManager] - mm-iface-modem.c:110] bearer_status_changed
0x7f5cdbad0903 [libgobject-2.0.so.0.3000.2] - gclosure.c:774] g_closure_invoke
0x7f5cdbae1dbb [libgobject-2.0.so.0.3000.2] - gsignal.c:3272] signal_emit_unlocked_R
0x7f5cdbaeac82 [libgobject-2.0.so.0.3000.2] - gsignal.c:3003] g_signal_emit_valist
0x7f5cdbaeae5e [libgobject-2.0.so.0.3000.2] - gsignal.c:3060] g_signal_emit
0x7f5cdbad3876 [libgobject-2.0.so.0.3000.2] - gobject.c:925] g_object_dispatch_properties_changed
0x7f5cdbad5ceb [libgobject-2.0.so.0.3000.2] - gobjectnotifyqueue.c:132] g_object_notify_by_pspec
0x7f5cdbd56b08 [ModemManager] - mm-bearer.c:112] bearer_update_status
0x7f5cdbd56ffd [ModemManager] - mm-bearer.c:393] disconnect_ready
0x7f5cdbbcc676 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:749] g_simple_async_result_complete
0x7f5cdbbcc788 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:761] complete_in_idle_cb
0x7f5cdb7cff44 [libglib-2.0.so.0.3000.2] - gmain.c:2441] g_main_context_dispatch
0x7f5cdb7d0597 [libglib-2.0.so.0.3000.2] - gmain.c:3089] g_main_context_iterate
0x7f5cdb7d0b51 [libglib-2.0.so.0.3000.2] - gmain.c:3297] g_main_loop_run
0x7f5cdbd4e331 [ModemManager] - main.c:150] main
0x7f5cdb1ea41c [libc-2.15.so] - libc-start.c:234] __libc_start_main
0x7f5cdbd4de48 [ModemManager] + 0x00019e48]
Reported by Ben Chan <benchan@google.com>
Some modems (e.g. Sierra Wireless MC7710 or ZTE MF820D) won't report LTE
capabilities even if they have them. So just run AT+WS46=? as well to see
if the current supported modes list includes any LTE-specific mode.
This is not a big deal, as the AT+WS46=? command is a test command with a
cache-able result, so the next time we need the command result (when loading
supported modes) the value will be loaded from the cache.
Current capabilities is the set of *active* radios that can be used
right now. Modem capabilities are the set of all radios the modem
could use, if some action were performed to enable them if they are
not enabled already (firmware reload, changing allowed mode, etc).
For QMI devices, the DMS Get Capabilities command represents all
radios, and thus "modem capabilities".
But to read *current* capabilities, ie active radios, we need to
query the NAS System Selection Preference and grab the "mode
preference" TLV. Unfortunately that is only available with NAS
>= 1.1, which means older Gobi devices (1K and 2K) don't support
it. So for older devices, we try to get the Technology Preference
(which takes into account user-requested limitations) and then
mask that with the DMS Get Capabilities result for a best-effort
current capabilities.
For example, the Pantech UML290VW reports DMS Get Capabilities
of "cdma, evdo, gsm, umts, lte", but a more limited SSP mode
preference according to what modes are actually enabled. Gobi
1K devices don't support SSP, and the DMS Get Capabilities
reports cdma/evdo or gsm/umts depending on the currently loaded
firmware. Previous to this patch, ModemManager reported all
modes as available on the UML290, ignoring what modes were
actually enabled.
