Sometimes SUPL-server based A-GPS is not possible, e.g. if the module
doesn't have Internet connectivity. In such cases, the modem may
support injecting additional "assistance data" that may be downloaded
from the Internet using external means (e.g. WiFi), in order to keep
having a quick time to first fix.
We now support using this location assistance data, with the following
new API elements:
* A new mask of supported assistance data types is provided in the
SupportedAssistanceData property.
* A new list of URLs from where the aassistance data may be
downloaded is also provided in a new AssistanceDataServers
property.
* A new InjectAssistanceData() method is provided, to perform the
data injection in the module once it's been downloaded to the host
system.
Unfortunately, G_MINDOUBLE is basically 0.0, so MM_SIGNAL_UNKNOWN ends
up giving us a value that may fall in the range of expected values for
the signal component.
Update the MM_SIGNAL_UNKNOWN symbol to match a value which is
definitely out any other possible valid range, so that we can easily
detect which values are set and which aren't.
While API is maintained, this fix is introducing an ABI break. Not a
big deal anyway, as the purpose of the value is just to detect unset
fields.
The "location area code" field is given in GSM/UMTS networks
exclusively. LTE networks use the concept of "tracking area code"
instead.
This patch updates the Location interface to Provide separate fields
for LAC and TAC, instead of giving TAC values in the LAC field.
==8663== 1 bytes in 1 blocks are definitely lost in loss record 5 of 4,864
==8663== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==8663== by 0x669FAC9: g_malloc (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66B9AEA: g_strndup (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66ACE52: g_match_info_fetch (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x4E96DD2: mm_location_gps_raw_add_trace (mm-location-gps-raw.c:208)
==8663== by 0x18721E: mm_iface_modem_location_gps_update (mm-iface-modem-location.c:264)
==8663== by 0x1B9C7F: loc_location_nmea_indication_cb (mm-shared-qmi.c:712)
==8663== by 0x640C9E7: g_cclosure_marshal_VOID__BOXEDv (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x6409C95: ??? (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x64259E8: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x642612F: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x54AAB2D: process_indication (qmi-loc.c:7454)
Reported by: Thomas Weißschuh <thomas@weissschuh.net>
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
This patch fixes a potential NULL referenece issue in
mm_cdma_manual_activation_properties_get_prl() where it accesses
`self->priv->prl->data' when `self->priv->prl' could be potentially
NULL.
This patch fixes a potential NULL referenece issue in
mm_sms_properties_get_data() where it accesses `self->priv->data->data'
when `self->priv->data' could be potentially NULL.
There are potential memory leaks in MMLocationGpsNmea:
- When the `trace' string provided to location_gps_nmea_take_trace() isn't
added to the hash table, its ownership is still considered transferred.
It should thus be freed. Similarly, the `trace_type' string isn't
added the hash table and should thus be freed.
- mm_location_gps_nmea_add_trace() duplicates a given trace string and
then passes the trace copy to location_gps_nmea_take_trace(). When
location_gps_nmea_take_trace() returns FALSE, the ownership of the
copy isn't transferred. mm_location_gps_nmea_add_trace() should thus
free the copy.
This patch fixes the above memory leaks by having
location_gps_nmea_take_trace() always take the ownership of the `trace'
string and internally free `trace' and `trace_type' when necessary.
The following checks in mm_modem_firmware_select() and
mm_modem_firmware_select_sync() could result in a NULL pointer
dereference if `unique_id' is NULL:
g_return_if_fail (unique_id != NULL || unique_id[0] == '\0')
g_return_val_if_fail (unique_id != NULL || unique_id[0] == '\0', FALSE)
This patch fixes the checks to properly verify that `unique_id' is
neither NULL nor an empty string.
Those Roman numeral suffixes in MM_MODEM_BAND_EUTRAN_* were replaced
with 1, 2, 3, ..., etc. This patch adds a compatibility header,
ModemManager-compat.h, to alias the old MM_MODEM_BAND_EUTRAN_* values to
the new values.
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
So that we don't leak the port names allocated within each
MMModemPortInfo.
==261== 672 bytes in 84 blocks are definitely lost in loss record 7,314 of 7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_strdup (gstrfuncs.c:363)
==261== by 0x44B5B73: g_variant_dup_string (gvariant.c:1529)
==261== by 0x44B945E: g_variant_valist_get_nnp (gvariant.c:4775)
==261== by 0x44B945E: g_variant_valist_get_leaf (gvariant.c:4945)
==261== by 0x44B945E: g_variant_valist_get (gvariant.c:5126)
==261== by 0x44B922C: g_variant_valist_get (gvariant.c:5161)
==261== by 0x44B9FC9: g_variant_get_va (gvariant.c:5388)
==261== by 0x44BA3C5: g_variant_get_child (gvariant.c:5486)
==261== by 0x6613FA8: mm_common_ports_variant_to_garray (mm-common-helpers.c:238)
==261== by 0x6601AB9: ensure_internal_ports (mm-modem.c:766)
==261== by 0x6603E42: mm_modem_peek_ports (mm-modem.c:825)
==261== by 0x65CD94D: owns_port (nm-modem-broadband.c:196)
Reported-by: Piotr Figiel <p.figiel@camlintechnologies.com>
==261== 482 bytes in 12 blocks are definitely lost in loss record 7,290 of 7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_strdup (gstrfuncs.c:363)
==261== by 0x44B5B73: g_variant_dup_string (gvariant.c:1529)
==261== by 0x44B945E: g_variant_valist_get_nnp (gvariant.c:4775)
==261== by 0x44B945E: g_variant_valist_get_leaf (gvariant.c:4945)
==261== by 0x44B945E: g_variant_valist_get (gvariant.c:5126)
==261== by 0x44B922C: g_variant_valist_get (gvariant.c:5161)
==261== by 0x44B9FC9: g_variant_get_va (gvariant.c:5388)
==261== by 0x44BA1DB: g_variant_get (gvariant.c:5335)
==261== by 0x664E2EF: mm_gdbus_modem_simple_call_connect_finish (mm-gdbus-modem.c:22451)
==261== by 0x6608A08: simple_connect_ready (mm-modem-simple.c:154)
==261== by 0x429136F: g_task_return_now (gtask.c:1107)
==261== by 0x4291A69: g_task_return (gtask.c:1165)
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
Aleksander Morgado
Ben Chan
Guido Günther
Enrico Mioso
Ville Skyttä
Piotr Figiel
Thomas Haller