| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Including tests for 5G-only and non-multimode 5G+4G and 5G+4G+3G devices.
|
|
|
|
|
|
The helper method for which we have unit tests available refers
exclusively to the current capabilities loading, so rename it to
clarify that.
|
|
|
|
|
|
Change due to update in current capabilities loading logic.
|
|
multimode device
We use capability switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE/5GNR or not) to add or remove the GSM/UMTS and CDMA/EVDO
capabilities.
Based on the same logic, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE+5GNR device:
"GSM/UMTS+CDMA/EVDO+LTE+5GNR", "GSM/UMTS+LTE+5GNR", "CDMA/EVDO+LTE+5GNR" and "LTE+5GNR"
Similarly, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE device:
"GSM/UMTS+CDMA/EVDO+LTE", "GSM/UMTS+LTE", "CDMA/EVDO+LTE" and "LTE"
And, we will allow 3 combinations for GSM/UMTS+CDMA/EVDO device:
"GSM/UMTS+CDMA/EVDO", "GSM/UMTS" and "CDMA/EVDO"
Also, supported combination modes should be based on current capabilities and not entirely
upon supported radio interfaces.
1) If current capability has "gsm-umts" or "cdma-evdo" or both, do not
support 4G only, 5G only, or 4G+5G combination modes
2) If current capability neither has "gsm-umts" nor "cdma-evdo", only support
combination modes involving 4G and 5G.
|
|
Keep LTE or 5GNR always in current capabilities if supported by device.
Since capability switching logic is exclusively used for configuring
GSM/UMTS+CDMA/EVDO devices, decide if to have GSM/UMTS or CDMA/EVDO or both
or none when loading current capabilities.
|
|
|
|
On MBIM modems the type of PIN cannot be specified in MBIM_CID_PIN query
command and the modem responds only remaining attempts for the currently
active lock.
If PIN1 is unlocked and user tries to disable (or enable) it, MM won't
get an update of remaining attempts in response to PIN Query. This value
is returned only after the Set command and MM need to store it in
all (pin/puk)_set_(enter/enable/change)_ready functions.
Previous solution was to call the mm_iface_modem_update_unlock_retries
directly from these functions but it caused the notification to be send
too early and invalid number was displayed to user sometimes.
Instead of this MM will store numbers of remaining attempts and send
them in a single notification from modem_load_unlock_retries.
|
|
This reverts commit 46c5cd8b7279e6139466664f87d744a0553fa1c3.
|
|
|
|
|
|
Newly refactored string manipulation function is leaking memory as per
our tests. This submission fixes that memory leak.
|
|
Changes on meson 0.61 makes the build to fail due to empty
annotations in some gdbus code generation[0].
Taking advantage of `kwargs` support, it has been changed to avoid
the issue.
Fixes #499
[0] https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/499
|
|
When using udev, we rely on the kernel to timely report port additions
in the same device.
When not using udev, e.g. when using hotplug scripts in openwrt, we
use mmcli --report-kernel-event operations to report the port
additions, which may end up requiring much more time to process,
especially during bootup as we would be reporting a lot of port
addition events one after the other.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/493
|
|
setup/cleanup/enable/disable
The finish() method with the GTask result propagation must be in the
same context as the GTask creation itself, not elsewhere.
Code is reordered so that the async methods can be read from bottom to
top, with the finish() method that includes the GTask result
propagation at the very top.
|
|
This uses the PDC Refresh indication to notify clients that
there is a new list of profiles.
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/477
|
|
To identify which devices support the firehose update protocol.
|
|
|
|
The 'update_settings' object must be referenced before the task is completed.
|
|
|
|
|
|
|
|
|
|
Implementing support for 5GNR cell info.
|
|
Implementing support for LTE cell info.
|
|
Implementing support for TDSCDMA cell info.
|
|
Implementing support for UMTS cell info.
|
|
Implementing support for GSM cell info.
|
|
Implementing support for CDMA cell info.
|
|
|
|
Generic base object to implement support for the different types of
cell infos.
Provides support for the 'serving' boolean, which is common to all.
|
|
This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
|
|
We were returning success on this operation upon an UNSUPPORTED error,
and we should keep on doing the same after all the indication support
changes.
|
|
We must keep a valid QmiClient reference for as long as the operation
runs, so that we can use it in all the request send operations we do,
and also so that we can remove the indication id upon completing the
operation.
The timeout id and indication id, which are also part of a single
power operation are also included in the operation context, because
they don't have any other meaning out of it.
The operation context is stored as task data.
|
|
|
|
As in the case of the timeouts, we should not pass a full reference as
data to the signal handler as we don't know how many times we'll
receive the signal or if we'll ever receive it.
We already make sure that the signal handler is disconnected when the
operation ends, so we can be sure the self pointer is valid while the
signal handler is connected.
|
|
|
|
The timeout may not be called if we remove it earlier (e.g. if the
indication is received) and therefore we must not pass a full new
reference, otherwise it may get leaked.
There is no problem with the validity of the self pointer in timeout
callbacks because we're removing the timeout as part of the operation
teardown logic.
|
|
We just created the GTask and we just updated the stored pointer,
checking for it being non-NULL at this point is a bit paranoid
|
|
|
|
If Mode online is triggered just after Mode LPM and Mode LPM
processing is not complete in modem, modem will not process the next
request and the device will be stuck in an unwanted modem power
state. Thus, wait for a mode change indication from the modem before
declaring that a power on/off has been successful.
|
|
Fibocom's documentation states that we must double-check the connection
is established when setting up an ECM connection. The possible replies -
according to the documentation - are:
+GTRNDIS: <state>,<cid>,<ip>,<prim. dns>,<sec. dns>
OK
or
+GTRNDIS: 0
We just care about the state value which is 1 if everything worked.
|
|
Some modems might have a net port but don't support +GTRNDIS which is
used by the ECM bearer. That case will be caught by this additional
check.
|
