| Age | Commit message (Collapse) | Author |
|---|
|
Based on the WDS client being connected, we'll convert this error into
"IPv4 only allowed" or "IPv6 only allowed".
|
|
Just a few key translations for now.
|
|
We register translations for QMI core and QMI protocol errors. These
translations are a best-effort, and they are not meant to be
exhaustive.
The original error description is included in the translated GError,
so that the details of the issue are not lost.
|
|
|
|
|
|
This allows us to skip needing to include the non-existent
build_string_from_mask() or get_string() counterparts in the
documentation index.
|
|
The personalization feature enum used in "card status" is different to
the one used in other UIM operations like "depersonalization".
libqmi dependency updated to 1.33.6 to ensure we can use the new types.
|
|
|
|
|
|
At the moment the endpoint type and number for the QMI WDA calls are
chosen based on the subsystem of the QMI control port. This does not
work correctly for some configurations:
- SUBSYS_QRTR currently implies ENDPOINT_TYPE_EMBEDDED, but this is
only valid for QRTR+IPA configurations. For QRTR+BAM-DMUX the
correct type is ENDPOINT_TYPE_BAM_DMUX.
- SUBSYS_WWAN currently implies ENDPOINT_TYPE_PCIE, but there is
already a comment that mentions that this selection works only for
MHI/PCIe modems. SUBSYS_WWAN is also used by RPMSG+BAM-DMUX
configurations in which case the correct type is also
ENDPOINT_TYPE_BAM_DMUX.
Looking closer at these cases suggests that the endpoint type actually
refers to the data/net port and not the control port. It is more
reliable choose it based on the network driver and not the subsystem
of the control port.
Address this partially by choosing the endpoint type based on the
net_driver. Choosing the endpoint interface number correctly requires
more refactoring since most of the logic is currently handled globally
for a QMI control port, while it's actually specific to the chosen
data/net port in some cases (e.g. multiple BAM-DMUX network interfaces).
|
|
If no DMS capabilities are reported, we fall back to the capabilities
reported by NAS SSP or NAS TP.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
|
|
The rights each contributor has are the ones stated by the GPL/LGPL,
not more and not less.
|
|
In GSM/UMTS+CDMA/EVDO multimode devices, the 4G and 5G mode switching
operations are exclusively limited to the capability selection that
has LTE+5GNR exclusively.
We cannot allow switching to 4G-only, 5G-only or 4G+5G if the current
capabilities have GSM/UMTS or CDMA/EVDO.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/503
|
|
|
|
|
|
The helper method for which we have unit tests available refers
exclusively to the current capabilities loading, so rename it to
clarify that.
|
|
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.
|
|
Implement support for the NR5G band list to get current NR5G bands.
This will also allow us to configure supported NR5G bands via mmcli.
|
|
Implement support for the NR5G band list to get supported NR5G
band capabilities.
localhost ~ # qmicli -d qrtr://0 --dms-get-band-capabilities
[qrtr://0] Device band capabilities retrieved:
Bands: 'bc-0-a-system, bc-0-b-system, bc-1-all-blocks, gsm-dcs-1800, gsm-900-extended, bc-10, gsm-850, gsm-pcs-1900, wcdma-2100, wcdma-pcs-1900, wcdma-1700-us, wcdma-850-us, wcdma-800, wcdma-900, wcdma-850-japan'
LTE bands: '1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29, 30, 32, 34, 38, 39, 40, 41, 42, 43'
LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29, 30, 32, 34, 38, 39, 40, 41, 42, 43, 46, 48, 66, 68, 71'
NR5G bands: '1, 2, 3, 5, 7, 8, 12, 13, 14, 18, 20, 25, 26, 28, 29, 30, 38, 40, 41, 48, 66, 70, 71, 77, 78, 79'
|
|
|
|
|
|
Support is added to set eid dbus interface property using
MBIM protocol when the inserted sim is esim.
|
|
|
|
On a failed QMI modem connection, we won't return the generic
"CallFailed" error, we'll try to convert the 3GPP verbose call end
reason to a MMMobileEquipmentError.
And if we cannot find a mapping, or if the reported error is not a
3GPP verbose call end reason, we'll return a Unknown
MMMobileEquipmentError with a string message providing detailed error
information.
|
|
|
|
Configuration
|
|
|
|
|
|
If we find that none of the requested auth settings are supported, we
should fail and return an error.
Also, make sure we set the CHAP fallback default only if either user
or password are given.
|
|
|
|
Add support for the Linux wwan subsystem that started to expose
control channel as character devices (e.g. /dev/wwan0p1MBIM...).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
|
|
Extend mm-port-qmi to accept a QRTR node to work with modems using the
QRTR protocol.
|
|
MM_BEARER_ALLOWED_AUTH_NONE
There is no point in returning UNKNOWN when the WDS auth value is NONE.
|
|
The acquisition order preference TLV must always have the same number
of elements, just the order of the elements should be different.
Also, always prefer the acquisition order preference TLV to the
GSM+WCDMA specific one, which is the same logic the modem applies.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/340
|
|
The endpoint info of a given MMPortQmi is immutable (it's associated
to the specific kernel driver in use and to the specific physical
interface number of the device).
We'll load it as soon as the kernel device object is set in the port,
and we'll keep it in the private struct so that it can be used at any
time, e.g. by the WDA Get/Set Data Format operations on newest
devices, where the endpoint info TLV is mandatory.
|
|
It makes much more sense than returning a gchar array, as gchar is
signed.
|
|
Optionally given explicitly, and -1 can be used to assume it's
NUL-terminated.
|
|
This util method checks whether the input string is a valid hex
string, so make sure we return a GError on failure.
|
|
|
|
|
|
Do it earlier, before running the parser.
|
|
No need to retry checking card status when the application state is
illegal, just treat the SIM card as unusable right away.
https://forum.sierrawireless.com/t/uim-card-application-state-illegal/21842
|
|
SIMs can be created with an EID fetched during load_sim_slots
while initializing the modem, if present.
Since load_eid would be implemented with the same mechanism
we avoid using it here (if Get Slot Status fails once, it
probably doesn't make a lot of sense to try it again).
|
|
DMS_UIM messages have been deprecated, and have been replaced by
equivalent UIM messages. Use UIM_GET_CARD_STATUS while querying for facility
locks if dms_uim messages were found to be deprecated.
|
|
The original logic that parsed the 'UIM Get Card Status Output' did a
bit of guessing to decide what was the current lock status to consider
in the modem. This guessing was fine on systems with a single SIM
slot, but it was very wrong as soon as multiple SIMs had to be
considered.
In a Multi-SIM Multi-Standby setup, with multiple SIMs reported as
active, we should look for the one flagged as "GW primary" to consider
it the primary SIM card of the system,the one required to start a data
connection.
We explicitly ignore the ones flagged as "1X primary", as we don't
consider a SIM card required in CDMA/EVDO setups.
|
|
This is going to be used in handling the multi-SIM setup, so make it a
common helper.
|
|
|
|
|
|
|
|
|
