| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
#698856)
For devices that support Sprint commands (SPSERVICE, SPERI) the CDMA1x
Serving System checks weren't run because at the time that decision was
made, they were AT-based and didn't provide anything useful above the
proprietary Sprint commands.
But now that we have QCDM serving system checks, which do provide the
SID and NID, we should just use them if we can. Otherwise we don't
get any SID/NID information on Sprint-command-supporting devices.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Icera devices include bands that the modem doesn't support in
the %IPBM=? list, so the plugin sets the band to its current
enabled/disabled value to test whether that band is supported.
There were two problems with this approach:
1) Setting an already-enabled band to be enabled apparently
isn't a NOP; it might take more than the 3 seconds given, and
if the response comes after 3 seconds, this greatly confuses
ModemManager because the AT command/reply sequence is now
messed up. So increase the timeout to 10 seconds.
2) Why bother checking bands that are already enabled anyway?
We already know they are supported, so just don't check those
bands at all. This requires some parkour because we use the
parsed band array from %IPBM=? to track whether bands are
enabled/disabled by indexing into the array, so instead just
use two separate arrays. This actually makes the fix for #1
un-needed (because we never enable any bands) but it's good
to have #1 anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
The USB305 (Icera-based) apparently has a port that replies to everything
with ERROR, and that port is unusable. Make sure it's ignored, otherwise
MM may claim it as the primary AT port since it technically speaks AT.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes a few unnecessary NULL checks on free(), which also fixes
the following clang warnings:
result.c:59:27: error: if statement has empty body [-Werror,-Wempty-body]
if (v->u.u8_array);
^
result.c:59:27: note: put the semicolon on a separate line to silence this warning
result.c:62:28: error: if statement has empty body [-Werror,-Wempty-body]
if (v->u.u16_array);
^
result.c:62:28: note: put the semicolon on a separate line to silence this warning
Bug reported on https://code.google.com/p/chromium/issues/detail?id=219280
Patched by Yunlian Jiang <yunlian@chromium.org>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The numbers reported by +SYSSEL may have more than one digit, e.g.:
+SYSSEL: 14,2,0,0
https://bugzilla.gnome.org/show_bug.cgi?id=698774
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
If SIM is not available, no 3GPP caps in current caps.
|
| |
|
|
|
| |
We already fully skipped SIM unlock check in 3GPP2-only devices; now we also
ignore SIM errors if the device is a 3GPP+3GPP2 device.
|
| |
|
|
|
|
|
|
|
| |
Use a static GString which will resize itself if the log message
is bigger than the current string size, but will also ensure we
don't do a ton of memory reallocation on every log message.
Previously all log messages were trucated at 512 bytes due to the
log buffer char array being 512 bytes long.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The specific case:
* Modem exposes cdc-wdm port, Generic plugin probes it successfully as QMI.
* Modem exposes new ports, including the wwan one. All ttys fail probing
because they're neither AT nor QCDM (CnS in this case).
* The wwan port ends up without a port being suggested and is not grabbed.
The root cause of this is that we do not propagate the suggested plugin to newly
added ports when it's the Generic one. If it wasn't the Generic one, the newly
added ports would start with the suggested one for probing.
Now, handle this by looking for the device-specified plugin when the port
probing ends without a specific port given. If there is such a device-specified
plugin accept the port, and otherwise, reject it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many multi-mode Qualcomm devices report all available modes in their
AT+GCAP response (for example, CDMA/EVDO and GSM/UMTS) but they cannot
actually function in all these modes at the same time. The modem's
actual current capabilities are expressed by the QCDM NV ModePref
item, which is not reflected in the AT+GCAP response.
Reading the current capabilities from the NV ModePref item ensures
that ModemManager does not create interfaces for the modem which
the modem cannot actually implement.
Because the generic modem plugin does not implement the Modem
Capabilities hook (because there is no standard way to determine
what access technologies a modem supports), the Current Capabilities
are copied to the Modem Capabilities. For devices that support
QCDM this means that Modem Capabilies which used to be created from
the GCAP response and thus would contain all available capabilities
now contain only current capabilities. This isn't a problem though
since there was no way to switch the devices to use any of their
other capabilities, becuase there aren't any standard commands for
it. Plugins that know how to switch their modem's capabilities
should (and they already do) override load_current_capabilities
and load_modem_capabilities to get the correct information.
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=698246
|
| |
|
|
|
| |
The helper functions got the return code of qcdm_result_* wrong
and thus failed all requests for pilot sets.
|
| | |
|
| |
|
|
|
|
| |
Use it if found, don't use it if not found.
Can be explicitly requested with --with-mbim.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
