| 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.
|
|
|
|
|
|
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).
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
This is going to be used in handling the multi-SIM setup, so make it a
common helper.
|
|
|
|
logging
|
|
|
|
|
|
If the manufacturer uses QMI unique IDs in ASCII, use the same format
in our APIs, instead of blindly converting them to a 16-byte HEX
string.
This makes user operations much nicer, e.g. instead of:
$ sudo mmcli -m 0 --firmware-list
----------------
Firmware | list: 02.20.03.00_GENERIC
| current: yes
| gobi pri unique id: 3030322E3031375F3030300000000000
| gobi modem unique id: 3F5F3F00000000000000000000000000
| 02.14.03.02_SPRINT
| current: no
| gobi pri unique id: 3030322E3031325F3030310000000000
| gobi modem unique id: 3F5F3F00000000000000000000000000
| 02.20.03.22_VERIZON
| current: no
| gobi pri unique id: 3030322E3032365F3030300000000000
| gobi modem unique id: 3F5F3F00000000000000000000000000
| 02.14.03.00_VODAFONE
| current: no
| gobi pri unique id: 3030302E3030385F3030300000000000
| gobi modem unique id: 3F5F3F00000000000000000000000000
We will have:
$ sudo mmcli -m 1 --firmware-list
----------------
Firmware | list: 02.20.03.00_GENERIC
| current: no
| gobi pri unique id: 002.017_000
| gobi modem unique id: ?_?
| 02.14.03.02_SPRINT
| current: no
| gobi pri unique id: 002.012_001
| gobi modem unique id: ?_?
| 02.20.03.22_VERIZON
| current: yes
| gobi pri unique id: 002.026_000
| gobi modem unique id: ?_?
| 02.14.03.00_VODAFONE
| current: no
| gobi pri unique id: 000.008_000
| gobi modem unique id: ?_?
|
|
This will allow us to configure via mmcli devices that support LTE
bands that would not fit in the standard TLVs (e.g. band 66 below)
or bands which aren't really reported in the standard TLVs (e.g. bands
46 and 48 below).
$ sudo qmicli -d /dev/cdc-wdm0 -p --dms-get-band-capabilities
[/dev/cdc-wdm0] Device band capabilities retrieved:
Bands: 'wcdma-2100, wcdma-pcs-1900, wcdma-1700-us, wcdma-850-us, wcdma-800, wcdma-900, wcdma-1700-japan, wcdma-850-japan'
LTE bands: '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 38, 39, 40, 41, 42, 43'
LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30, 32, 38, 39, 40, 41, 42, 43, 46, 48, 66'
|
|
This commit introduces several improvements and changes in the way
modes and capabilities are managed in QMI capable devices. It is
organized into a single commit, as all changes in all 6 operations
(load current capabilities, load supported capabilities, set current
capabilities, load supported modes, load current modes, set current
modes) are related one to the other (given that the same QMI commands
are used for both capabilities and mode management).
The primary change is related to which capabilities are reported as
supported for a given device. In the previous implementation we
allowed switching between every combination possible for GSM/UMTS+LTE,
CDMA/EVDO+LTE or GSM/UMTS+CDMA/EVDO+LTE devices. E.g. we would allow
"LTE only" and "GSM/UMTS only" capabilities for GSM/UMTS+LTE devices,
even if they would both be managed in exactly the same way. That setup
wasn't ideal, because it meant that switching to a "LTE only"
configuration would require a power cycle, as capability switching
requires a power cycle, even if no change was expected in the exposed
DBus interfaces (which is why we require the power cycle). So, instead
of allowing every possible capability combination, we use capability
switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE or not) to add or remove the
GSM/UMTS and CDMA/EVDO capabilities. E.g. for a GSM/UMTS+CDMA/EVDO+LTE
device we would allow 3 combinatios: "GSM/UMTS+LTE", "CDMA/EVDO+LTE"
and "GSM/UMTS+CDMA/EVDO+LTE".
The "GSM/UMTS+CDMA/EVDO+LTE" is a special case because for this one we
allow switching to "LTE only" capabilities while we forbid switching
to "4G only" mode. As the same commands are used for mode and
capability switching, if we didn't have "LTE only" and we allowed "4G
only" mode instead and rebooted the device, we would end up not being
able to know which other capabilities (GSM/UMTS or CDMA/EVDO or both)
were also enabled.
Now that we have capability switching confined to a very subset of
combinations, we can use the mode switching logic to e.g. allow "4G
only" configurations in all non multimode devices, as well as masks of
allowed modes with one being preferred, which we didn't allow before.
In the previous implementation all mode switching logic was disabled
for LTE capable QMI devices. In the new implementation, we use the
"Acquisition Order Preference" TLV in NAS Set System Selection
Preference to define the full list of mode preferences for all
supported modes.
We also no longer just assume that NAS Technology Preference is always
available and NAS System Selection Preference only after NAS >= 1.1.
This logic is flawed, instead we're going to probe for those features
once when loading current capabilities, and we then just implement the
capabilities/mode switching logic based on that.
|
|
|
|
This facility cannot be retrieved via 'DMS UIM Get CK Status' and seems
currently unimplemented for mm-broadband-modem-qmi. The SIM enabled
status is however available via 'DMS UIM Get PIN Status'.
Using this message to add the retrieval of PIN status just after the
other facilities were queried.
Succesfully tested with Gobi2000 (05c6:9205), both retrieval of 3gpp
SIM lock status and enabling/disabling the PIN.
|
|
|
|
|
|
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
|
|
|
|
Instead of just a mask of MMModemMode values, we now provide a list of the
allowed and preferred mode combinations supported by the modem. E.g.:
$> sudo mmcli -m 0
-------------------------
Modes | supported: 'allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 2g, 3g; preferred: none
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 3g; preferred: 3g
| allowed: 4g; preferred: none
| allowed: 2g, 3g, 4g; preferred: none'
|
|
Based on Dan's tests with QMI modems.
|
|
|
|
|
|
|
|
If none of the specified methods is supported, an error is returned.
|
|
The "NAS Get System Selection Preference" response may come without "Mode
Preference". If that is found, look for "Band Preference" and "LTE Band
Preference" TLVs and try to build capabilities from those.
This makes my UML290 properly report CDMA/EVDO+LTE capabilities:
ModemManager[16586]: [/dev/cdc-wdm0] Received message...
>>>>>> QMUX:
>>>>>> length = 55
>>>>>> flags = 0x80
>>>>>> service = "nas"
>>>>>> client = 1
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 43
>>>>>> message = "Get System Selection Preference" (0x0034)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = "Emergency mode" (0x10)
>>>>>> length = 1
>>>>>> value = 00
>>>>>> translated = 0
>>>>>> TLV:
>>>>>> type = "Band Preference" (0x12)
>>>>>> length = 8
>>>>>> value = 07:00:00:00:00:00:00:00
>>>>>> translated = 7
>>>>>> TLV:
>>>>>> type = "CDMA PRL Preference" (0x13)
>>>>>> length = 2
>>>>>> value = FF:3F
>>>>>> translated = 16383
>>>>>> TLV:
>>>>>> type = "Roaming Preference" (0x14)
>>>>>> length = 2
>>>>>> value = FF:00
>>>>>> translated = 255
>>>>>> TLV:
>>>>>> type = "LTE Band Preference" (0x15)
>>>>>> length = 8
>>>>>> value = 00:00:00:00:00:00:00:00
>>>>>> translated = 0
ModemManager[16586]: KEY: 01:00:01:03:00:00:00:00
ModemManager[16586]: Service: 03
ModemManager[16586]: Client ID: 01
ModemManager[16586]: Transaction ID: 01:00
ModemManager[16586]: <debug> [1347005734.979115] [mm-broadband-modem-qmi.c:321] load_current_capabilities_get_system_selection_preference_ready(): Mode preference not reported in system selection preference
ModemManager[16586]: <debug> [1347005734.979131] [mm-broadband-modem-qmi.c:333] load_current_capabilities_get_system_selection_preference_ready(): Valid bands reported in system selection preference: 'bc-0-a-system, bc-0-b-system, bc-1-all-blocks'
ModemManager[16586]: <debug> [1347005734.979141] [mm-broadband-modem-qmi.c:341] load_current_capabilities_get_system_selection_preference_ready(): LTE band preference found
ModemManager[16586]: [/dev/cdc-wdm0] Sending message...
<<<<<< QMUX:
<<<<<< length = 12
<<<<<< flags = 0x00
<<<<<< service = "dms"
<<<<<< client = 1
<<<<<< QMI:
<<<<<< flags = "none"
<<<<<< transaction = 1
<<<<<< tlv_length = 0
<<<<<< message = "Get Capabilities" (0x0020)
ModemManager[16586]: KEY: 01:00:01:02:00:00:00:00
ModemManager[16586]: Service: 02
ModemManager[16586]: Client ID: 01
ModemManager[16586]: Transaction ID: 01:00
ModemManager[16586]: <debug> [1347005734.982676] [mm-at-serial-port.c:392] debug_log(): (ttyACM0): <-- '<CR><LF>OK<CR><LF>'
ModemManager[16586]: <debug> [1347005734.982751] [mm-serial-port.c:969] mm_serial_port_close(): (ttyACM0) device open count is 2 (close)
ModemManager[16586]: <debug> [1347005734.982797] [mm-at-serial-port.c:392] debug_log(): (ttyACM0): --> 'AT+CMEE=1<CR>'
ModemManager[16586]: [/dev/cdc-wdm0] Received message...
>>>>>> QMUX:
>>>>>> length = 38
>>>>>> flags = 0x80
>>>>>> service = "dms"
>>>>>> client = 1
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 26
>>>>>> message = "Get Capabilities" (0x0020)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = "Info" (0x01)
>>>>>> length = 16
>>>>>> value = B0:9D:57:00:00:DD:6D:00:03:02:05:01:02:04:05:08
>>>>>> translated = [ max_tx_channel_rate = '5742000' max_rx_channel_rate = '7200000' data_service_capability = '3' sim_capability = '2' radio_interface_list = '{ [0] = '1 ' [1] = '2 ' [2] = '4 ' [3] = '5 ' [4] = '8 '}' ]
ModemManager[16586]: KEY: 01:00:01:02:00:00:00:00
ModemManager[16586]: Service: 02
ModemManager[16586]: Client ID: 01
ModemManager[16586]: Transaction ID: 01:00
ModemManager[16586]: <debug> [1347005734.983353] [mm-broadband-modem-qmi.c:183] modem_load_current_capabilities_finish(): loaded current capabilities: cdma-evdo, lte
|
|
|
