This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
We were re-using the GDBusObjectManagerClientFlags set in the
MMManager object as GDBusProxyFlags for the Manager1 interface proxy
object, and that was completely broken.
Instead of setting "DO_NOT_AUTO_START" in the proxy, we were actually
setting "DO_NOT_LOAD_PROPERTIES"...
g_assert_cmpmem() isn't available until glib 2.46, while the minimum
glib version required by ModemManager is 2.36. This patch replaces the
uses of g_assert_cmpmem() with memcmp() instead.
The $GNGGA traces provide "combined" values when multiple satellite
constellations are used (e.g. GPS+GLONASS). Prefer these values over
the GPS-only $GPGGA traces if both are received.
E.g. China Mobile (MCC 460, MNC 0).
$ mmcli -m toby --location-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
3GPP location | Mobile country code: '460'
| Mobile network code: '0'
| Location area code: '6188'
| Cell ID: '40955'
-------------------------
GPS NMEA traces | Not available
-------------------------
Raw GPS | Not available
-------------------------
CDMA BS | Not available
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.
Aleksander Morgado
Dan Williams
Ben Chan
Thomas Haller
Guido Günther
Enrico Mioso
Ville Skyttä