Several plugins define specific udev tags that must be available in
the device in order for the plugins to use them. Let's use these tags
as a direct indication that ModemManager can probe the devices.
In particular, this change would make all Ericsson MBM modems probed
right away also in STRICT filter mode, without needing to check the
ttyACM interface type or the available net ports.
If the signal is automatically disconnected during object disposal, we
shouldn't explicitly try to disconnect it ourselves during finalize().
Reported by: Lubomir Rintel <lkundrak@v3.sk>
This tag is completely redundant because users can whitelist the
platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS
tag, which is part of the explicit whitelist filter rule.
The udev tag that allows flagging devices that MAY be modems
(e.g. USB<->RS232 adapters) is only applicable to TTY devices, so
explicitly specify that in the tag name as well.
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
ussd_decode() expects a non-null GByteArray while process_ussd_message()
could potentially passes a null GByteArray to ussd_decode(). This
patch fixes the issue by having process_ussd_message() always creates a
GByteArray.
For devices which do not provide feature_extended_lte_band_preference
mm_modem_bands_to_qmi_band_preference() gets called from
mm_shared_qmi_set_current_bands() with extended_qmi_lte_bands
set to NULL which may cause a SIGSEGV in the memset() call in
mm_modem_bands_to_qmi_band_preference().
Avoid this by checking whether extended_qmi_lte_bands is non-NULL
before calling memset().
Reported-by: Nick <mips171@icloud.com>
Never automatically flag the bearer as disconnected if it's using PPP,
because we could end up using the TTY at the same time as pppd, with
the wrong CLOCAL settings.
So, whenever we detect that the bearer requires PPP, we will ignore
all disconnection reports generated by ModemManager itself.
mm_firmware_update_settings_get_variant() checks for a null `self'
pointer when accessing `self->priv->method', but doesn't perform the
null check when accessing other members of
MMFirmwareUpdateSettingsPrivate.
This patch fixes mm_firmware_update_settings_get_variant() to fully
handle a null `self' pointer.
mm-shared-qmi.c:358:9: error: variable 'mcc' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~
mm-shared-qmi.c:367:9: note: uninitialized use occurs here
if (mcc) {
^~~
mm-shared-qmi.c:358:9: note: remove the '&&' if its condition is always true
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~~~~
mm-shared-qmi.c:339:51: note: initialize the variable 'mcc' to silence this warning
guint16 mcc;
^
= 0
The modem may take the request to set modes and reply right away with
a success before actually changing the current modes in use.
Therefore, If we reload modes right after we receive the set response,
we may still see the old modes instead of the new ones. Try to avoid
this, by reloading current modes a couple of times after we have set
them if they are not yet the expected ones.
The modem may take the request to set bands and reply right away with
a success before actually changing the current bands in use.
Therefore, If we reload bands right after we receive the set response,
we may still see the old band mask instead of the new one. Try to
avoid this, by reloading current bands a couple of times after we have
set them if the band mask is not the expected one.
These new methods allow querying and updating the status of the call
waiting network service, as per 3GPP TS 22.083.
The status of the service is not a property because we don't want to
unconditionally load it on every boot, given that the process involves
talking to the network (i.e. it is not a device setting).
The tool monitors SMS message additions and SMS state updates, e.g.:
$ sudo ./test/mmsmsmonitor
[/org/freedesktop/ModemManager1/SMS/0] sms found: received
[/org/freedesktop/ModemManager1/SMS/1] sms found: received
[/org/freedesktop/ModemManager1/SMS/2] sms found: received
[/org/freedesktop/ModemManager1/SMS/3] sms found: received
[/org/freedesktop/ModemManager1/SMS/4] sms found: received
[/org/freedesktop/ModemManager1/SMS/5] sms found: received
[/org/freedesktop/ModemManager1/SMS/6] sms found: received
[/org/freedesktop/ModemManager1/SMS/7] new sms: receiving
[/org/freedesktop/ModemManager1/SMS/7] sms updated: received
The QMI NAS Initiate Network Register command will return a successful
response when the request to register is received and accepted by the
module, but this does not mean the requested registration has been
completed yet.
This issue was making e.g. manual registration attempts to a forbidden
network report success right away, even if the actual registration
would end up failing.
In order to avoid that, the QMI based network registration relies on
receiving QMI NAS Serving System indications after QMI NAS Initiate
Network Register replies. As soon as we get a non-searching
registration state in the indication, we'll report the operation as
successful.
Note that the 3GPP interface logic is anyway in charge of checking
if the specific request was successful or not, no need to do that
explicitly in the QMI implementation.
