We no longer have separate mm_base_modem_process_sim_event() and
mm_broadband_modem_sim_hot_swap_detected() methods. The only
difference between both of them was that one of them would attempt to
cleanup the ports context associated to the SIM hot swap event logic
as soon as a swap was detected, in order to avoid queueing up multiple
such events.
The previous logic wasn't working well, though, as there could be
mixed AT+QMI or AT+MBIM devices that would also require that same
cleanup and so we didn't always know which one should have been
called.
Now we have a single mm_iface_modem_process_sim_event() method, which
will trigger the reprobe and disabling, but which will also perform
the cleanup of the SIM ports swap setup as specified by the
implementation.
So, if a plugin explicitly initializes the serial ports context for
SIM hot swap handling, it should also explicitly clean it up.
Also, the initialization of the serial ports context for SIM hot swap
handling is no longer done automatically for all modems, it will be
done only for those modems using it; i.e. the modems that explicitly
report support SIM hot swap handling using AT URCs.
This property is used in the MMIfaceModem to flag whether the SIM hot
swap setup has been performed or not. The flag is now moved to the
iface-specific private context.
The property was also used in AT-based modems, so that implementations
supporting the SIM hot swap via AT URCs could flag the upper layers
whether the enabling of the feature was done correctly or not, and if
so, create and keep the AT ports context open. But this feature only
made sense in AT-based modems, i.e. an MBIM modem that detects SIM hot
swaps via MBIM indications exclusively should not require the AT ports
context open for anything. The check in the MMBroadbandModem object
has therefore been removed, and the logic will be updated so that it
only applies to AT-based modems.
It is important to gracefully stop the session before starting the
next session, making sure the engine is completely stopped. This can
be ensured by waiting for the +XLSRSTOP URC just after having received
the +XLSRSTOP command response.
We'll do an explicit wait for that URC with a 10s timeout, in order to
avoid waiting forever if the URC is never received. It will be assumed
that the engine is off if the 10s timeout happens, in the same way as
we were doing until now.
During the wait time for the URC, the operation task ownership is
shared among the response processor, the URC handler and the timeout
source. Once any of them decides to complete the task, the others will
automatically avoid attempting to complete the same task.
Based on a patch originally developed by:
Som_SP <somashekhar.puttagangaiah@intel.com>
The PLS63 is a drop-in replacement for PLS62 model, however it uses
different USB SoC and enumerates differently on the USB bus.
This commit adds relevant type hints with a correct Vendor and Product
IDs so that the device is correctly discovered. Without these type hints
the modem would not work correctly as it uses wrong port for PPP.
In some cases the "base" software package string does not have the
currently expected format of \d{2}.\d{2}.\d{3}. Specifically the last
triplet of characters might not be digits. For example a valid version
string might be 25.20.-04, which the current regex is unable to parse.
This change replace the previous regex with one less restrictive,
checking only the first part of the version's format.
g_date_time_new, and g_date_time_new_utc return NULL if inputs are out
of range, and currently mm_new_iso8601_time passes the GDateTime created
by those two functions to date_time_format_iso8601 without checking for
NULL values, causing a g_date_time_format_iso8601 crash if PDU data is
corrupted with wrong date.
To prevent this, mm_new_iso8601_time now can return NULL and set a new
GError if GDateTime created by g_date_time_new is NULL.
Fixes#546
Currently the Telit modem implements modem_after_sim_unlock() with 1s
timeout, however the #QSS URC management (introduced later) waits for
QSS=1 URC in csim_unlock_periodic_check up to 3s, which makes this 1s
delay not necessary anymore.
see also:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/3
Some modems, like LE910C1-EUX, express the LTE part of #BND output in
HEX format, but currently the MM parser for such case is limited to
modems that have "ext_4g_bands". This commits use the new MMTelitModel
info to decide how to parse #BND command output.
Fixes#487
Telit revision string can be used to identify the specific model, which
in turn is useful to specialize the behavior of the plugin.
This change adds revision parsing to detect some telit modems. Initially
it adds the ones that have different behaviors in #BND output parsing
for example.
Currently, firmware revision string is obtained via AT+CGMR or AT+GMR
commands from the default mm-broadband-modem. For a class of Telit
modems however this command does not return the actual Telit Software
Package version, but the "Modem FW Version", which is only a component
of the whole firmware. For this class of modems, the correct string is
obtained with "AT#SWPKGV" command.
This change overrides load_revision* functions to add the ability to
parse "AT#SWPKGV" command for the modems that support it, and falls back
to the same logic that was implemented in mm-broadband-modem otherwise.
foxconn modules get firmware version:
Try with the new FOX service first. If FOX service failed, try with DMS service.
T99W175(vid:105b) ; T77W968(0489:e0b4 ; 0489:e0b5):
qmi service: dms
T99W265(0489:e0da ; 0489:e0db):
qmi service: fox
The port to the meson build system a set of defines were lost, that
made the udev rules and the keyfiles tests to not run properly.
This has been changed so defines are now in their proper place and
tests are run properly.
Fixes#537
The numeric fields in the +COPS=? response were relying on a very weak
parsing logic, assuming that they were single-digit numeric values and
not using the common string to integer conversion utilities.
This commit improves the conversion from the 3GPP/ETSI defined network
availability and access technology values to the MM defined ones,
providing enum-based matches even if the numeric values are the same.
The commit also fixes the parsing of access technology values > 10,
required to report 5G related values.
The set_initial_eps_bearer_settings() operation is the same in XMM
capable and generic MBIM modem objects. Place it in a common shared
interface so that we don't duplicate code.
Use the same logic always to decide which is the best GPS control/data
port, and then perform the initial port setup (GNSS engine off) only
that single port.
We're not going to implement all XMM shared operations from the shared
utils, as the newer Intel modems support the new operations in the
Microsoft MBIM Extensions.
Just inherit the GNSS management capabilities.
meson generates the `mm-daemon-enums-types` source and header files.
These are used when building `ModemManager` executable and different
plugins. However, these enums are only stated as dependencies on the
`ModemManager` executable build.
This has been fixed by also adding the generated files targets as
dependencies in the required plugins.
The `broadmobi`, `dlink`, `telit` and `tplink` plugins include the
`mm-port-enums-types.h` header. However, they do not use any symbol
defined there.
The `huawei` plugin as includes the `mm-port-enums-types.h` header
but it does not include the build targets as dependencies.
These issues have been fixed by removing the unnecessary includes
from `broadmobi`, `dlink`, `telit` and `tplink` plugins and by
including the enums build target in the `huawei` target.
This silents a warning given by udev:
Configuration file /usr/lib/udev/rules.d/77-mm-fibocom-port-types.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
We won't create a full new different modem object based on whether the
ID_MM_FIBOCOM_INITIAL_EPS_OFF_ON tag is found or not. Instead, we
always will create the same object type, and detect whether the OFF/ON
cycle is required during runtime.
Assume that the method to change the initial EPS bearer settings is
always implemented in the parent, so that we can avoid the runtime
check.
This also fixes the codepath that would happen if the
iface_modem_3gpp_parent->set_initial_eps_bearer_settings == NULL
condition was valid, as that would end up with a GTask never completed.
When the attach APN settings are changed, the device will go through a
radio on -> radio off -> radio on cycle so that the new changes are
taken into consideration.
This change is done in a Fibocom-specific MBIM modem implementation
because it's working around a firmware bug that would prevent for the
attach settings to be considered automatically.
