- Jun 02, 2018
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that exposes a single ttyUSB0, these udev events happen: add /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device) add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface) add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial) add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial) bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface) bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device) Our udev rules in MM only added tags in the 'add' events, and it looks like the only ones 'persistent' after this sequence are those of the last event happening on the specific path. This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would be stored for later check (e.g. if ModemManager is started after these rules have been applied), which was ok. "udevadm info -p ..." would show these tags correctly always. But this also meant that the 'bind' udev event happening for the USB device didn't get any of our device-specific tags, and so we would be missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started after the last event has happened. "udevadm info -p ..." would not show these tags. Modify all our rules to also run at the 'bind' events. See, for context: https://github.com/systemd/systemd/issues/8221
-
-
- May 27, 2018
-
-
Aleksander Morgado authored
There are two ways to report new received SMS messages: * For class 0 (flash) messages, MBIM_CID_SMS_READ are sent. The SMS comes in the MBIM indication itself. * For non-class 0 (standard) messages, a MBIM_CID_SMS_MESSAGE_STORE_STATUS notifications are sent, the SMS is stored and must be read with an additional MBIM request specifying storage index. The names of the functions we had implied the opposite, we were assuming flash/alert messages were reported via MBIM_CID_SMS_MESSAGE_STORE_STATUS, not via MBIM_CID_SMS_READ.
-
Aleksander Morgado authored
Do not automatically probe serial ports under the 'pci' or 'sdio' platform drivers unless explicitly tagged with ID_MM_PLATFORM_DRIVER_PROBE. $ realpath /sys/class/tty/ttyS0/ /sys/devices/pci0000:00/0000:00:16.3/tty/ttyS0 $ basename $(realpath /sys/devices/pci0000:00/0000:00:16.3/subsystem) pci
-
Aleksander Morgado authored
The logic implementing the network timezone loading was holding a strong reference to the modem (inside the GTask) while waiting to be registered. This was triggering some possible memory leaks as the modem object could have been left around even after the modem was disconnected. E.g. if the modem booted without antennas plugged in, it was never getting registered, and if we unplugged it right away in that state, the network timezone logic would have left a modem reference around without disposing it. This issue, combined with e.g. other interfaces relying on disposing its own logic with the last object reference (e.g. Signal interface sets up its logic in a context bound to the lifetime of the object) would mean that a lot of different logic blocks were kept running even after the modem device was unplugged from the system. We avoid this issue by making sure that no new additional reference is taken by the logic in charge of updating the network timezone. We just make the timezone update context be bound to the lifetime of the object, as other interfaces do. While doing this, we also remove the logic in charge of "cancelling" the context, as it isn't needed. If the logic needs to be cancelled, we would just remove any configured timeout, which is enough. As part of the changes, the logic has also been improved so that the network timezone isn't only updated the first time the modem gets registered. If the modem gets unregistered and re-registered, we would reload the network timezone information.
-
- May 24, 2018
-
-
Dan Williams authored
nozomi and qcaux only drive modems and thus should be included in this filter rule. Allows nozomi/qcaux devices to work automatically with strict filter mode.
-
Dan Williams authored
-
- May 22, 2018
-
-
Dan Williams authored
From 3GPP TS 27.007 version 11.6.0 Release 11, sections 9.2.1, 9.2.2.1, 9.2.2.2, and 9.2.2.3.
-
- May 20, 2018
-
-
Gemalto's PLS8 may timeout on 3 second CIND query. Debug log shows 5 seconds should suffice.
-
- May 18, 2018
-
-
This patch extends commit c9e85b67 ("iface-modem-3gpp: ignore initial registration check result when appropriate") to handle the situation where a registration check update may prematurely transition the modem to the 'enabled' state while the modem is still being enabled. The issue is identified by Dan Williams <dcbw@redhat.com>. More details can be found in https://bugs.freedesktop.org/show_bug.cgi?id=106468
-
- May 08, 2018
-
-
Aleksander Morgado authored
The quick AT probe procedure is only meaningful to avoid waiting the +READY URC delay. If there is no such delay configured, we shouldn't run the quick AT probe (as a failure in the AT probe may also trigger a +READY URC delay). Just read the udev tag value early and complete the task if the delay is not configured.
-
Added reading the ID_MM_UBLOX_PORT_READY_DELAY udev flag value and using it as an init delay when a value is set. The 20 second delay for the TOBY-L4 +READ URC has been reimplemented using the new ID_MM_UBLOX_PORT_READY_DELAY udev value.
-
- May 07, 2018
-
-
Aleksander Morgado authored
This was preventing TTY-only ZTE and Huawei modules from being grabbed in STRICT mode. https://bugs.freedesktop.org/show_bug.cgi?id=106253 https://bugs.freedesktop.org/show_bug.cgi?id=106234
-
- Apr 30, 2018
-
-
For the TOBY-R2, LISA-R2, and LARA-R2, the only valid AT ports are ttyACM0, ttyACM1, and ttyACM2. All other ttyACM ports cause MM to wait 20-30 seconds probing the port on startup. Ignoring the non-AT ttyACM ports allows MM to not wait 20-30 seconds probing and therefore startup much faster with these modems.
-
Aleksander Morgado authored
The PDP contexts that are found with an empty APN configured are right now used as placeholders that can be overwritten with the user provided APN if no direct match is found. We want to keep that logic in place, but for the case where we do get an empty APN requested by the user, we need to perform the full context match, so that the first PDP context matching the empty APN is used. Right now we're overwriting with the empty APN again the last PDP context found with an empty APN, which doesn't make much sense: Apr 27 08:15:21 ModemManager[4251]: <debug> Found '3' PDP contexts Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=1] [type='ipv4'] [apn=''] Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=2] [type='ipv4'] [apn='broadband'] Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=15] [type='ipv4'] [apn=''] Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 1 and no APN Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 15 and no APN Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 3 (open) Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 2 (close) Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): --> 'AT+CGDCONT=15,"IP",""<CR>' Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): <-- '<CR><LF>OK<CR><LF>'
-
Aleksander Morgado authored
If the serial port timeout detection logic is enabled, warn whenever more than one consecutive command timeout happens, not just when the limit is reached.
-
-
- Apr 25, 2018
-
-
Commit 708b00ae "modem: allow periodic signal check to be disabled" added a "iface-modem-periodic-signal-check-disabled" property in MMIfaceModem/MMBroadbandModem to indicate if the periodic signal check should be disabled. If the property is set to TRUE, the signal_quality_polling_supported field of SignalCheckContext is set to FALSE, which is sticky across modem disable/enable operations. However, that is undesirable as we would like to issue an initial signal check to refresh the signal quality value after the modem is re-enabled from a state when the RF may have been previously turned off.
-
- Apr 24, 2018
-
-
ModemManager currently relies on unsolicited MBIM_CID_SIGNAL_STATE notifications to obtain signal quality updates, and it doesn't query the initial signal quality. It's been observed that some MBIM modems issue a MBIM_CID_SIGNAL_STATE notification only when there is a notable change in RSSI. The signal quality may remain at 0 for quite some time. It's more noticeable when simply restarting ModemManager after the modem has been initialized and enabled once. We could simply enable periodic signal check on an MBIM modem, but that's less ideal as it may unnecessarily wake the modem up from USB selective suspend (unless we use a much longer polling period). To address the issue, this patch adds the implementation of load_signal_quality to MMBroadbandModemMbim so that the signal quality is initially polled via a solicited MBIM_CID_SIGNAL_STATE query. To avoid the periodic signal check, we set the MM_IFACE_MODEM_PERIODIC_SIGNAL_CHECK_DISABLED property to TRUE for MMBroadbandModemMbim.
-
ModemManager decides to disable periodic signal check if either load_signal_quality is not implemented or load_signal_quality returns an unsupported error. However, in some cases, we want to use load_signal_quality to query the initial signal quality but rely on unsolicited signal quality updates from the modem afterwards without periodically polling for signal quality. To support that, this patch introduces a property in MMIfaceModem/MMBroadbandModem to indicate if the periodic signal check should be disabled.
-
Keeps build with GCC 8 happy. mm-base-call.c:758:18: warning: variable 'response' set but not used [-Wunused-but-set-variable] mm-base-call.c:822:18: warning: variable 'response' set but not used [-Wunused-but-set-variable] mm-base-sms.c:908:18: warning: variable 'response' set but not used [-Wunused-but-set-variable] mm-sms-list.c:331:25: warning: variable 'ctx' set but not used [-Wunused-but-set-variable] mm-iface-modem-messaging.c:1210:21: warning: variable 'storage_ctx' set but not used [-Wunused-but-set-variable] huawei/mm-plugin-huawei.c:183:18: warning: variable 'response' set but not used [-Wunused-but-set-variable] ublox/mm-plugin-ublox.c:161:24: warning: variable 'response' set but not used [-Wunused-but-set-variable] ublox/mm-plugin-ublox.c:159:24: warning: variable 'ctx' set but not used [-Wunused-but-set-variable] icera/mm-modem-helpers-icera.c:218:25: warning: variable 'first_free' set but not used [-Wunused-but-set-variable] novatel/mm-common-novatel.c:50:18: warning: variable 'response' set but not used [-Wunused-but-set-variable]
-
It's annoying for distributors to build with -Werror, since it means that compiler upgrades can break the build. Let's let them disable it, but keep it enabled by default.
-
- Apr 03, 2018
-
-
Aleksander Morgado authored
The 'any' mode refers to the mode which includes most access technologies and where none of them is preferred. Fix the logic so that all combinations with one technology preferred over the others are ignored, instead of the other way around. Fixes assertion with the 4G-only LARA R204. ModemManager[424]: <debug> [-192499452.090358] (ttyACM0): --> 'AT+URAT=?<CR>' ModemManager[424]: <debug> [-192499452.092150] (ttyACM0): <-- '<CR><LF>+URAT: (3)<CR><LF><CR><LF>OK<CR><LF>' ** ERROR:ublox/mm-modem-helpers-ublox.c:817:mm_ublox_get_modem_mode_any: assertion failed: (any != MM_MODEM_MODE_NONE) Reported-by: Matthew Starr <mstarr@hedonline.com>
-
- Mar 27, 2018
-
-
Aleksander Morgado authored
-
- Mar 13, 2018
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
So that we don't forget to add new types here manually... (e.g. MMBearerStats)
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Mar 09, 2018
-
-
Aleksander Morgado authored
We used ttyACM0 as secondary port until now, just because we had an extra AT capable TTY around in addition to the main control ttyACM2 port. Turns out, using this ttyACM0 may actually break the connection setup in the wwan interface in a bad way (e.g. not allowing DHCP setup). The suggestion from u-blox and Intel is to fully ignore ttyACM0; and given that we no longer need any primary/secondary port logic, we just remove all the associated udev tags.
-
- Mar 04, 2018
-
-
Aleksander Morgado authored
From: Andika Triwidada <andika@gmail.com> https://bugs.freedesktop.org/show_bug.cgi?id=105337
-
- Feb 23, 2018
-
-
Aleksander Morgado authored
-
Releasing the port on the device looks benign but because it emits a signal, it could call device_context_port_released and unref the MMDevice in port_context_unref. This means the MMDevice might be disposed before we get to the g_object_ref and the subsequent call to g_hash_table_remove will try to hash a null string, which makes MM crash.
-
- Feb 21, 2018
-
-
The hashtable is keyed on the UID of the MMDevice, and its hash function is g_str_hash. We shouldn't be passing a GObject into g_hash_table_remove because calling g_str_hash on an MMDevice is wrong.
-
- Feb 13, 2018
-
-
MM was not updating the EPS registration status for qmi modems. This led to LTE-only modems never having 'registered' status. This was happening for Quectel EC21-V modem.
-
- Feb 08, 2018
-
-
Dan Williams authored
In mm_iface_modem_3gpp_register_in_network() when deciding whether to force automatic registration or not, check whether the modem is already registered in a network. Just checking whether we have a valid operator code is not sufficient, as some modems (ublox Toby R2xx) don't always return an operator name/code even when registered.
-