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.
mm_device_create_modem needs a valid object_manager instance to create the new
modem, while the one provided before was cleared out by a call to
mm_device_remove_modem few lines before.
Since the newly created modem refers to the same HW device, we can use
the same object_manager also.
https://bugs.freedesktop.org/show_bug.cgi?id=99160
So that different concurrent runs of this same test don't clash with
each other:
TEST: test-service-generic... (pid=11124)
/MM/Service/Generic/enable-disable: Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
** (plugins/.libs/lt-test-service-generic>:11124): ERROR **: Cannot bind socket: Error binding to address: Address already in use
cleaning up pid 11144
FAIL
Looks like gdbus-codegen ends up making paragraphs and that breaks the
XML parsing:
DOC Building HTML
../../../../libmm-glib/generated/mm-gdbus-doc-org.freedesktop.ModemManager1.xml:60: parser error : Opening and ending tag mismatch: variablelist line 59 and para
</para><para> <varlistentry><term><literal>action</literal></term>
^
../../../../libmm-glib/generated/mm-gdbus-doc-org.freedesktop.ModemManager1.xml:110: parser error : Opening and ending tag mismatch: para line 110 and variablelist
</para><para> </variablelist>
^
../xml/ModemManager-dbus-reference.xml:93: element include: XInclude error : could not load ../../../../libmm-glib/generated/mm-gdbus-doc-org.freedesktop.ModemManager1.xml, and no fallback was found
This is so that "make check" doesn't depend on having the rule files
installed in the default udev rules directory, which currently would
break the build:
TEST: test-service-generic... (pid=2601)
/MM/Service/Generic/enable-disable: Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
** (/home/aleksander/Development/foss/ModemManager/plugins/.libs/lt-test-service-generic:2601):
ERROR **: Error setting test profile: GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Failed to find primary AT port
FAIL
GTester: last random seed: R02S3897abaae9df36f8d2eeb679406ab675
make[3]: *** [Makefile:3804: test-nonrecursive] Terminated
The original g_udev_device_get_property_as_int() uses strtol() without
an explicit base (i.e. 0) so that the base is autodetected from the
string whenever possible (e.g. if prefixes with '0x' it is treated as a
hexadecimal string).
But, for ID_USB_INTERFACE_NUM, we explicitly require reading the number
as an hex string, even if we don't have any '0x' prefix.
Reported-by: Matthew Stanger <stangerm2@gmail.com>
If a port has been flagged as ignored with the ID_MM_PORT_IGNORE udev property,
we shouldn't open and probe the ports in any way, just flag them as ignored. We
still report them in the list of modem ports, but just with "unknown" type and
therefore not using them for anything.
Since automake 1.11.2 it is recommended that packages
use AM_DISTCHECK_CONFIGURE_FLAGS instead of
DISTCHECK_CONFIGURE_FLAGS as the latter is intended
to be a user variable.
https://bugs.freedesktop.org/show_bug.cgi?id=95826
Telit LE922A does not like the legacy way for checking pin status, but
instead of returning QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND, it returns
QMI_PROTOCOL_ERROR_NOT_SUPPORTED, making the modem not to be fully
initialized.
This patch adds QMI_PROTOCOL_ERROR_NOT_SUPPORTED as another error for
which the new pin checking status way is tried.
This is the value which we actually suggest in the manpage for the mmcli
operation, so just use the same one.
Scanning for 3GPP networks may really take a long time, so a specific timeout must be given:
$ mmcli -m 0 --3gpp-scan --timeout=300
Found 4 networks:
21404 - Yoigo (umts, available)
21407 - Movistar (umts, current)
21401 - vodafone ES (umts, forbidden)
21403 - Orange (umts, forbidden)
https://bugs.freedesktop.org/show_bug.cgi?id=98235
What's left enabled:
* Access to /dev -- obviously
* CAP_SYS_ADMIN -- this is needed by TIOCSSERIAL only. Too bad this also
allows TIOCSTI, which allows for code injection unless something else
(SELinux) disallows access to ttys with shells.
Maybe kernel should use CAP_SYS_TTY_CONFIG for this.
* socket(AF_NETLINK) -- udev & kernel device changes
* socket(AF_UNIX) -- D-Bus
