It sometimes provides a much better view of the supported modes than the WS46=?
command, which is not always properly implemented. E.g.:
Nokia N950:
---------------
at+ws46=?
(12)
OK
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA,HSUPA
OK
Sierra AC313u
---------------
at+ws46=?
ERROR
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA/HSUPA,HSPA+,LTE
OK
We may be asking to load supported modes while in locked state, so the commands
may fail. In order to re-load them properly once we're unlocked, we better just
return an error instead of setting defaults.
We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
For CDMA-only devices, we will default to IPv4.
For 3GPP devices, we will use the AT+CGDCONT=? test command to query which are
the supported PDP types.
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
If the context is already defined, then we can just use it instead
of calling +CGDCONT to create it again. Modems don't like this,
plus it's pointless.
https://bugzilla.gnome.org/show_bug.cgi?id=701151
Some QMI modems seem to fail when requesting to list all SMS messages in a given
storage. When this happens, we'll loop through all storages but performing per
tag list requests.
If the bearer is connected and we get a notification of being unregistered, wait
up to 15s to force the disconnection, in case we can recover the registration
in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=699803
A value 0 is used to denote an invalid/uninitialized CID. This patch
fixes a CID check in disconnect_3gpp() of MMBroadbandBearer such that it
disables all PDP contexts via AT+CGACT=0 when no specific CID is used
(i.e. cid == 0).
This patch updates normalize_ciev_cind_signal_quality() in
MMBroadbandModem to remove an unnecessary check on 'quality >= 0' and
also makes sure the normalized signal quality is capped at 100 when no
maximum is specified.
This is revised from a patch originally authored by
Yunlian Jiang <yunlian@chromium.org>.
Bug reported on https://code.google.com/p/chromium/issues/detail?id=235989
For some reason a number of ZTE CDMA devices want the whole QCDM
frame in one USB transaction, or at least don't like it being
broken up and sent byte-by-byte with a send delay. They simply
don't respond. Since testing indicates that every other QCDM
capable device I've got also handles a zero send delay on both
3.8.8 and 2.6.32, lets just set it to zero for everything,
which should speed things up a bit too.
https://bugzilla.gnome.org/show_bug.cgi?id=698869
The GetNetworkTime() response is defined to be an ISO8601 string, which
is in turn defined to be in local time. Make sure that's reflected in
the documentation, and append the timezone offset to UTC where we have
it.
Oddly, Icera devices return their time info in UTC with an offset to
the local timezone, so we have to jump through some hoops there to
convert the response to localtime based on the reported offset.
Some additional fixes by Aleksander Morgado <aleksander@lanedo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=697372
If no capabilities could be determined from the modem's responses,
result would be NULL but no error would be set, since the modem
didn't time out or have some other critical error, it simply didn't
report any recognized capabilities. Ensure that an error is
reported in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=698845
You can't g_array_insert_val() to an index that's beyond the end
of the array, which was happening if the user tried to set the
band list to "any":
mmcli -m 0 --set-bands=any
Just use g_array_append_val() instead.
==5618== Invalid read of size 2
==5618== at 0x4A0A158: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:881)
==5618== by 0x326201D8FB: g_array_insert_vals (string3.h:57)
==5618== by 0x442EFB: mm_iface_modem_set_bands (mm-iface-modem.c:1982)
==5618== by 0x44307E: handle_set_bands_auth_ready (mm-iface-modem.c:2100)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x4358E3: authorize_ready (mm-base-modem.c:1300)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x326386E0F8: complete_in_idle_cb (gsimpleasyncresult.c:787)
==5618== by 0x3262047A54: g_main_context_dispatch (gmain.c:2715)
==5618== by 0x3262047D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==5618== by 0x3262048181: g_main_loop_run (gmain.c:3484)
==5618== by 0x426235: main (main.c:142)
==5618== Address 0x10a7ea74e is not stack'd, malloc'd or (recently) free'd
==5618==
==5618==
==5618== Process terminating with default action of signal 11 (SIGSEGV)
==5618== Access not within mapped region at address 0x10A7EA74E
==5618== at 0x4A0A158: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:881)
==5618== by 0x326201D8FB: g_array_insert_vals (string3.h:57)
==5618== by 0x442EFB: mm_iface_modem_set_bands (mm-iface-modem.c:1982)
==5618== by 0x44307E: handle_set_bands_auth_ready (mm-iface-modem.c:2100)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x4358E3: authorize_ready (mm-base-modem.c:1300)
==5618== by 0x326386DFF6: g_simple_async_result_complete (gsimpleasyncresult.c:775)
==5618== by 0x326386E0F8: complete_in_idle_cb (gsimpleasyncresult.c:787)
==5618== by 0x3262047A54: g_main_context_dispatch (gmain.c:2715)
==5618== by 0x3262047D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==5618== by 0x3262048181: g_main_loop_run (gmain.c:3484)
==5618== by 0x426235: main (main.c:142)
This patch adds a 'bearer-default-ip-family' property to MMBearer, which
specifies the default IP family to use for a bearer when no explicit
value is given via the simple connect properties. The default IP family
is set to IPv4 in MMBearer but can be overridden by a MMBearer subclass,
which allows a modem plugin to specify an appropriate default value.
It seems that really old Gobi 1K firmware (from ~2008) doesn't implement
the SetDataFormat command, and will simply ignore the request without
replying to it. But the device works just fine if we retry the
QMI port open operation without the SetDataFormat request.
The downside of this is is that on older kernels, the qmi_wwan driver
won't automatically fix up any raw-ip packets it receives, but the
old Gobi devices don't ever send raw-ip packets anyway, so it's not
a problem.
The MC7710 will report a MBIM_SUBSCRIBER_READY_STATE_SIM_NOT_INSERTED status
when initializing and the SIM is not ready yet. So retry a couple of times as we
do for MBIM_SUBSCRIBER_READY_STATE_NOT_INITIALIZED. If all retries are consumed,
get the last reported status to build the error.
This change makes all modems without SIM require up to 10s to get fully
initialized and exposed in DBus; but it shouldn't be a big deal as the modems
are unusable anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=698264
We don't support SIM/RUIM on CDMA devices (yet), so for now it makes
no sense to run the after-sim-unlock step on CDMA-only devices where
a SIM won't be present.
Unfortunately we don't know at this point whether there is a SIM
or not, so if the modem is a multi-mode device (implying it has a SIM
slot) and its plugin implements the modem_after_sim_unlock() hook,
the hook will still be executed and might cause an unecessary delay
when a SIM is not inserted.
Dan Williams
Aleksander Morgado
Dmitry Ivanyushin
Ben Chan