When calling g_list_free_full() to free a GList in dispose(), it is
necessary to reset the GList pointer to NULL as dispose() may be called
more than once.
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
In functions
- mm_broadband_modem_lock_sms_storages
- modem_messaging_set_default_storage
return with error when using current_sms_mem1_storage as +CPMS value, but
current_sms_mem1_storage value is UNKNOWN.
On modems with a single TTY for both control and data, we cannot use
the TTY to load connection status once we're in connected mode:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
...
So, disable connection monitoring right away if that situation is
detected:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
Connection monitoring is unsupported by the device
...
https://bugs.freedesktop.org/show_bug.cgi?id=100376
When the connection request is done via ATD, flag the port as
connected as soon as the successful response is received, so that we
remove our polling on the device right away.
https://bugs.freedesktop.org/show_bug.cgi?id=99541
The +CGSM capability is saying that the modem is a 3GPP modem, but
that doesn't necessarily mean it's a GSM/UMTS modem, it could be a
LTE-only device.
We did add the GSM_UMTS capability when +CGSM was found, so now we'll
check if the device only reports 4G-only mode, and remove the
capability if so.
https://bugs.freedesktop.org/show_bug.cgi?id=100155
A new 'ID_MM_TTY_BAUDRATE' per-port udev tag is introduced, which
allows specifying the baudrate that will be used when opening a
specific serial port.
E.g.:
ACTION!="add|change|move", GOTO="mm_my_modem_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.3/*", ENV{ID_MM_TTY_BAUDRATE}="115200"
LABEL="mm_my_modem_end"
https://bugs.freedesktop.org/show_bug.cgi?id=100158
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties are currently expected in the physical device
(e.g. ID_MM_PLATFORM_DRIVER_PROBE) while some others are expected in
each port (e.g. the plugin udev tag filters).
This patch tries to simplify the logic and just assume that the device
specific tags may be given in either the physical device or the port
device, by providing separate APIs to retrieve port-specific or
device-specific (global) properties. If the same tag is given in both
the device and the port, the one in the device takes preference.
For the generic backend, these new APIs are really useless, as all
device-specific and port-specific properties are always stored in the
port object themselves (there is no 'tree' of devices in the generic
backend, no 'physdev' device).
For the udev backend, though, there really is a difference, as the
tags may be set in port or device.
https://bugs.freedesktop.org/show_bug.cgi?id=100156
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
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
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
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
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 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.
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
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.
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
These CDC ACM class devices are docking stations for Sigma Sport bike
computers. As they are sensitive to single byte commands, ModemManager
probing mechanism actually caused training data on attached bike
computer to be zeroed.
https://bugs.freedesktop.org/show_bug.cgi?id=96430
u-blox modems will append a string showing the MCC and MNC info to the access
point name listed in AT+CGDCONT? responses. We will try to detect when that
happens, and we just accept the match.
The logic doesn't just look for a string prefix; it also looks for the special
MCC + MNC suffix, which is much more restrictive, to try to avoid false
positives.
Provide a generic +CESQ based implementation for the extended Signal interface,
applicable to all AT-based modems.
We explicitly disable this check in MBIM modems.
Ben Chan
Carlo Lobrano
Aleksander Morgado
Dan Williams
Maksim Salau
Matthew Stanger
Carlo Lobrano
Daniele Palmas
Sławomir Bocheński