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.
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.
Get/Set Technology Preference was introduced in NAS 1.0, so should be always
available (even if we thought it was introduced in NAS 1.7, that's not true).
But the newer System Selection Preference behaves better as it allows more
features like 'preferred' modes; so use it when available (NAS >= 1.1).
This is the port to git master of the following commit:
commit 01201860de5565a78823913423c6b2a762e3731f
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 21:12:14 2012 -0500
core: speed up QCDM probing a bit
The point of sending two "version info" commands was to ensure that
the terminating 0x7E of the first one was processed as a QCDM frame
boundary and that any random data in the buffer (like AT commands
from probing) got cleared out. The second command would always
get processed as a valid QCDM command if the device supported QCDM,
since there was no garbage before it.
Instead of that dance, just prepend the version info message with
an extra 0x7E to ensure a clean QCDM frame which the device hopefully
responds to immediately. Second, actually process that response
instead of throwing it away. Should save about 3 seconds when
probing QCDM ports.
This is the port to git master of the following commit:
commit 1d9164ec90788d1be134482ff88c501e3c5d623c
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Aug 27 18:20:33 2012 -0500
gsm: if the generic CNMI request fails, try a Qualcomm-compatible one
Many devices based on Qualcomm chipsets don't support a <ds> value
of '1', despite saying they do in the AT+CNMI=? response. But they
do accept '2'. Since we're not doing much with delivery status
reports yet, if we get a CME 303 (not supported) error when setting
the message indication parameters via CNMI, fall back to the
Qualcomm-compatible CNMI parameters.
If we don't do this, we don't get SMS indications on these devices,
because the original CNMI failed.
Tested on Huawei E1550, Huawei E160G, ZTE MF622, and Novatel XU870.
This is the port to git master of the following commit:
commit 1c29ce5999d11dee2898e7bf41c00995a00c71d0
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Aug 27 17:36:49 2012 -0500
sms: fix handling of 'data' property for multipart messages
Text was getting concatenated when reconstructing the full message,
but the data wasn't. That meant that non-text multipart messages,
like the binary APN/MMS settings messages that operators often send,
were broken.
This is a port to git master of the following commit:
commit 0b051f9c7033143c56f59267794d1cadf4bd3416
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Aug 27 10:24:50 2012 -0500
gsm: better handling of IMSI response
Moto EZX devices prefix the response with "+CIMI:" while most
devices do not.
This is the port to git master of the following patch:
commit 21e66dfa1774ac2ee037ac8b6e8bb4d71a6f7931
Author: Dan Williams <dcbw@redhat.com>
Date: Thu Aug 23 21:13:35 2012 -0500
core: add function to open probe ports without removing echo
Some devices (Sierra GSM ones) return stuff we need but don't
bother to prefix it with <CR><LF>, so we need to optionally turn
off the echo removal at probe time.
Don't abort the connection if the modem reports unregistered in either
3GPP or CDMA, as mixed CDMA+3GPP modems may connect even if not registered
in both technologies.
QMI and wwan ports come in pairs. Each wwan port has an associated control QMI
port, which is the only port allowed to send the Start|Stop Network QMI requests
to start|stop the connection in the given wwan interface.
Paired QMI and wwan interfaces (should) share the same parent udev device,
quoting Bjørn:
"If we ignore the unfortunate 3.4 and 3.5 kernels, then a matching wwanX
and cdc-wdmY set will always share the same parent USB interface on QMI
devices.
Having the same parent USB device is *not* sufficient. You cannot control
wwan0 using cdc-wdm1 in the above example."
Aleksander Morgado
Ben Chan
Marius B. Kotsbak
Dan Williams