Adding the vendor string match allows us to support RS232 devices in
the Telit plugin: the USB vendor id check may now be ignored and
instead we probe for the vendor string via AT commands, which works
even if the device is behind a USB<->RS232 adapter.
https://bugs.freedesktop.org/show_bug.cgi?id=100171
The telit plugin is based on two main ways of checking the purpose of
each port: udev tags flagging specific interfaces (with info taken
from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
the modem about that information. If none of those applies, the port
is ignored by default.
In order to support devices that are not explicitly tagged, the plugin
shouldn't flag as ignored the AT-capable TTYs, instead they are now
grabbed as 'secondary': ports grabbed as secondary will never be used
for either primary/data IF there is another port flagged explicitly
for primary/data.
This fixes the support for modems with a single TTY and no explicit
port type hint tag, e.g. RS232 modems with just one single TTY where
there's no point in specifying port type hints: the port will be
grabbed as secondary, and then automatically promoted to primary/data
as there is no other port grabbed.
https://bugs.freedesktop.org/show_bug.cgi?id=100159
If a device reports "LTE" in the list of current capabilities, we'll
set EPS network supported by default. This will enable CEREG
registration checks for AT based devices.
If a device reports only "LTE" in the list of current capabilities, we
disable all the other network support flags (e.g. will disable CREG
and CGREG checks among others).
https://bugs.freedesktop.org/show_bug.cgi?id=100170
Since we process the WDS Event Report Indication messages, we need
libqmi from git master, so we bump the required version to the first
tag that contains those QMI messages.
If the device support check fails, either with an error, or afterwards
when trying to create a modem object, we must remove the MMDevice from
the tracking table of devices, so that a manual scan request
afterwards re-scans all ports.
https://bugs.freedesktop.org/show_bug.cgi?id=100157
Two main changes in the regex:
* Ignore double quotes around interval numbers.
* Ignore second set of values (i.e. the one after the comma), as it
may not even be given).
We now support at least these two formats:
^SCFG: "Radio/Band",("1-511","0-1")
^SCFG: "Radio/Band\",("1"-"147")
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
clear_modem() can be invoked from set_property() and dispose(), where
`self->priv->modem' may be NULL. This patch adds a null check on the
modem object to make sure we don't run g_object_run_dispose() on a null
modem object.
find_device_by_physdev_uid() expects a non-NULL UID of the physical
device. However, mm_kernel_device_get_physdev_uid() could potentially
return NULL on MMKernelDeviceUdev if find_physical_gudevdevice() in
mm-kernel-device-udev.c fails to find the physical device. When a NULL
physical device UID is passed to find_device_by_physdev_uid() and used
in g_hash_table_lookup(), it leads to a crash in g_str_hash(), which is
a bit obscure.
This patch updates kernel_device_get_physdev_uid() in
mm-kernel-device-udev.c to fall back to use the device sysfs if the
physical device sysfs isn't available, which is similar to how
kernel_device_get_physdev_uid() mm-kernel-device-generic.c is
implemented.
The parent method would use QCDM to load access tech, but we already
have the access tech reported in MBIM via indications, so no real need
to mix that.
For context, see:
https://bugs.freedesktop.org/show_bug.cgi?id=100000
This patch simplifies the handling of platform/pci/pnp/sdio device in
find_physical_gudevdevice(). When the code finds the first parent device
under the subsystem 'platform', 'pci', 'pnp', or 'sdio', it stops
traversing up the device tree, so there is no need to keep track of
whether a platform / pci / pnp / sdio device has previously been visited
via those is_platform/is_pci/is_pnp/is_sdio Boolean variables.
A few crashes have been observed in the field with the following signature:
Thread 0 CRASHED [SIGSEGV @ 0x00000000 ] MAGIC SIGNATURE THREAD
0xf53ff5e8 (libglib-2.0.so.0.3600.4 -ghash.c:1732 ) g_str_hash
0xf53fe8c7 (libglib-2.0.so.0.3600.4 -ghash.c:365 ) g_hash_table_lookup
0xb953c3bd (ModemManager -mm-base-manager.c:130 ) device_removed
0xb953cc9f (ModemManager -mm-base-manager.c:408 ) handle_uevent
0xf54c535f (libgobject-2.0.so.0.3600.4 -gclosure.c:777 ) g_closure_invoke
0xf54d6fc7 (libgobject-2.0.so.0.3600.4 -gsignal.c:3584 ) signal_emit_unlocked_R
0xf54d7baf (libgobject-2.0.so.0.3600.4 -gsignal.c:3328 ) g_signal_emit_valist
0xf54d7fa5 (libgobject-2.0.so.0.3600.4 -gsignal.c:3384 ) g_signal_emit
0xf5623819 (libgudev-1.0.so.0.2.0 -gudevclient.c:104 ) monitor_event
0xf540cc51 (libglib-2.0.so.0.3600.4 -gmain.c:3054 ) g_main_context_dispatch
0xf540cfa5 (libglib-2.0.so.0.3600.4 -gmain.c:3701 ) g_main_context_iterate
0xf540d2c5 (libglib-2.0.so.0.3600.4 -gmain.c:3895 ) g_main_loop_run
0xb9539dad (ModemManager -main.c:180 ) main
0xf52d687d (libc-2.23.so -libc-start.c:289 ) __libc_start_main
0xb9539bf3 (ModemManager + 0x0001cbf3 ) _start
0xb95b0fbf (ModemManager -elf-init.c:87 ) __libc_csu_init
0xf56dbe43 (ld-2.23.so + 0x0000be43 ) _dl_sort_fini
0xb9539bbf (ModemManager + 0x0001cbbf ) _init
The crash happens when mm-kernel-device-udev.c:find_physical_gudevdevice()
fails to find the physical device, which eventually leads to a NULL
`physdev_uid' being passed to g_hash_table_lookup() in
mm-base-manager.cc:find_device_by_physdev_uid().
There isn't much information about the actual device that triggered the
udev event, but it's suspected to be a tty or net device on a SDIO bus
and thus associated with a physical device on the 'sdio' subsystem. This
patch updates find_physical_gudevdevice() in mm-kernel-device-udev.c to
handle this particular scenario.
Two issues here:
1) PCH_SLEEP wasn't considered a "wcdma_open" state, but it should be
since the modem is still registered and can be attached in this state
2) If the system mode is WCDMA (eg, not GSM and not GSM/WCDMA) then
MM shouldn't assume GPRS if WCDMA isn't "open", since GPRS isn't
enabled in WCDMA-only mode
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100000
The enum was wrong. There isn't actually an L1M_INIT state; the
enum should start with L1M_IDLE. There should also be a
L1M_PCH_SLEEP state between DEACTIVATE and DEEP_SLEEP.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100000
* Allow whitespaces prefixing the values row.
* Allow more than one \r\n between the title and the table header.
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
Don't rely on the automatic disconnection of the signal as the last
reference of the modem object may outlive the device object.
Also, setup a common clear_modem() function to dispose the internal
reference of the modem object, which will take care of the signal
disconnection when required.
https://lists.freedesktop.org/archives/modemmanager-devel/2017-February/003907.html
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.
This patch fixes an uninitialized variable issue in
mm_ublox_parse_ugcntrd_response_for_cid(), which uses an uninitialized
`match_info' when `in_cid' is invalid.
This patch fixes a bug in packet_service_status_indication_cb(), which
incorrectly treats the MMBearerStatus enum value returned by
mm_base_bearer_get_status() as a MMBearerConnectionStatus enum value.
MMBearerStatus and MMBearerConnectionStatus can't be used
interchangeably as they have different enum values for the
'disconnected' and 'disconnecting' state.
`g_assert_true' and `g_assert_false' are defined in glib 2.38 or later.
The minimum glib version currently required by ModemMamanger is 2.36.
While `g_assert_true' and `g_assert_false' may be preferred over the
more generic `g_assert', it seems like overkill to bump the minimum glib
version requirement just for that. When more code in ModemManager later
requires newer versions of glib, we can migrate all existing code to use
`g_assert_true' and `g_assert_false' when appropriate.
The suggestion to use specific PDP context CIDs was given by Cinterion
for the special case of the Verizon operator, which 'reserves' specific
CIDs for specific purposes.
We don't want to impose that at the Cinterion plugin level, so remove
the PDP context mapping we had.
Therefore, simplify the connection procedure by just overriding the
'dialing' step of the default 3GPP connection sequence, instead of
overriding the whole connection sequence.
Also, we don't need to override the step to gather IP config because
this is already handled by the generic plugin (for DHCP over a network
interface).
We port to GTask for both 3GPP dial and 3GPP disconnect at the same time.
Better check for ^SWWAN support during the first time a bearer is going
to be created.
The enabling phase isn't the correct one because this logic is only run
whenever a modem is detected but not hotplugged (i.e. this step is to
'reset' the modem to generic runtime settings).
We get as input the ^SWWAN index we're interested in, and we loop
through the list of ^SWWAN lines looking for the one we need.
This updated helper method allows working with multi-line ^SWWAN
responses, e.g. given when more than one PDP context is active.
Group together all connection related logic (e.g. context) and define
the context steps directly within the connection sequence processing.
Also, don't initially run a disconnection before the connection; if that
logic is ever needed we should likely have it in the generic modem, not
done per plugin.
And error out early if not asking for IPv4.
