| Age | Commit message (Collapse) | Author |
|---|
|
This new error type will be used to report errors in the carrier lock
operations performed through ModemManager.
They have a one to one mapping to the MBIM status specific errors.
|
|
We register translations for MBIM core, MBIM protocol and MBIM status
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.
|
|
Moved to the end of the file, we'll add all new error translations
together.
|
|
|
|
Fixes 470dff235c70683928ab0eb39c64151a8a4ceb7c
|
|
Use the Packet Service messages to report the state of PS domain,
instead of guessing.
|
|
This allows us to skip needing to include the non-existent
build_string_from_mask() or get_string() counterparts in the
documentation index.
|
|
MbimDataClass is a flags bitmask, not an enumeration.
This logic was broken if the reported data class was e.g. 4G+5GNSA.
|
|
On MBIM modems that do not support mbimex v2, extra steps are required
to retrieve 3G/4G signal quality markers from the modem when using
thresholds to trigger signal quality indications.
|
|
The Tethering context type UUID was defined by Microsoft in its
extensions as `5e4e0601-48dc-4e2b-acb8-08b4016bbaac` (along with
others like Admin, Xcap, App and EmergencyCalling), see
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/mb-provisioned-context-operations.
These UUIDs are expected to be usable only if the modem supports
`MBIM_CID_MS_PROVISIONED_CONTEXT_V2` (CID=1) in the Basic Connect
Extensions service (3d01dcc5-fef5-4d05-0d3abef7058e9aaf).
If the modem doesn't support these, we should try to fallback to a
more generic APN type automatically, e.g. "Internet", which was
defined in MBIM 1.0 and should always be supported.
There should be no problem in a modem to have 2 separate PDN
connections with the same context type.
|
|
|
|
|
|
Handling of gdbus interface changes for additional
properties(service cell type and bandwidth) in
broadband modem mbim.
Co-author: Shilpa Shivakumar
|
|
Some modems (e.g. Telit FN990) reports 5G capabilities in CustomDataClass
field of device-caps cid: take this into account when building the
modes according to the data caps.
|
|
|
|
MbimProviderState is a bitset, so don't try to match exact values in a
switch statement when converting to MMModem3gppNetworkAvailability.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/524
|
|
When the modem sends an error which is outside the range
defined in MBIM_NW_ERROR list then MM should use a default
error(MBIM_NW_ERROR_NONE) instead of crash.
|
|
|
|
MbimProvisionedContextElementV2
Microsoft defined a new extended version of the "provisioned contexts"
operation from the generic MBIM basic connect service. This extended
version adds several new settings that can be stored in the profile
(e.g. IP type, media type, roaming allowance...).
But this new version has a huge drawback; we cannot specify single
profiles via their unique id while we perform update/delete operations
in the modem. Instead, Microsoft explains that we should use the
context type to identify the target context; but this will ONLY work
if we have one context defined for each type. As soon as we have
multiple contexts of the same type, this operation may fail or
otherwise update multiple contexts at once.
|
|
|
|
|
|
Whenever MBIMEx v3.0 is enabled, the logic should create requests and
parse responses using the updated format.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
|
|
|
|
|
|
|
|
We process the MBIM signal state notification and use it to update the
extended signal quality information in the Signal interface.
|
|
|
|
Just for completeness.
|
|
Use the new Preferred Data Classes field in the Register State v2
message in order to know if the modes requested in the Set message are
the expected ones or not.
Based on an initial implementation by Som_SP <somashekhar.puttagangaiah@intel.com>
|
|
When we enable MBIMEx v2.0, the "Signal State" responses and
indications no longer report a valid RSSI value; and instead, they
report per access technology RSRP/RSRQ values.
>>>>>> Header:
>>>>>> length = 116
>>>>>> type = indicate-status (0x80000007)
>>>>>> transaction = 0
>>>>>> Fragment header:
>>>>>> total = 1
>>>>>> current = 0
>>>>>> Contents:
>>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>>>>>> cid = 'signal-state' (0x0000000b)
>>>>>> Fields:
>>>>>> Rssi = '99'
>>>>>> ErrorRate = '99'
>>>>>> SignalStrengthInterval = '5'
>>>>>> RssiThreshold = '2'
>>>>>> ErrorRateThreshold = '4294967295'
>>>>>> RsrpSnr = '{
>>>>>> [0] = {
>>>>>> Rsrp = '0'
>>>>>> Snr = '0'
>>>>>> RsrpThreshold = '4294967295'
>>>>>> SnrThreshold = '4294967295'
>>>>>> SystemType = '5g-nsa'
>>>>>> },
>>>>>> [1] = {
>>>>>> Rsrp = '49'
>>>>>> Snr = '45'
>>>>>> RsrpThreshold = '4294967295'
>>>>>> SnrThreshold = '4294967295'
>>>>>> SystemType = 'lte'
>>>>>> },
>>>>>> }'
|
|
|
|
Support is added to set eid dbus interface property using
MBIM protocol when the inserted sim is esim.
|
|
Instead of having a switch with a lot of cases, provide a one to one
mapping for the MbimNwError and MMMobileEquipmentError codes in an
array, and make use of the mm_mobile_equipment_error_for_code() helper
to build the actual GError.
|
|
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
|
|
|
|
We use the "Provisioned Contexts" message support to add and edit
profiles.
We also use the same message, with context-type set to "none" to
attempt deleting it, although that doesn't seem to be fully supported
by all modems. E.g. the EM7345 (FIH7160_V1.1_MODEM_01.1349.12) will
still report contexts 'deleted' in this way, with the context-type set
to "none".º
|
|
For strstr()
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/301
|
|
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
|
|
|
|
mm-modem-helpers-mbim.c: In function ‘mm_mobile_equipment_error_from_mbim_nw_error’:
mm-modem-helpers-mbim.c:206:5: error: enumeration value ‘MBIM_NW_ERROR_IMEI_NOT_ACCEPTED’ not handled in switch [-Werror=switch-enum]
206 | switch (nw_error) {
| ^~~~~~
mm-modem-helpers-mbim.c: In function ‘mm_bearer_ip_family_from_mbim_context_ip_type’:
mm-modem-helpers-mbim.c:403:5: error: enumeration value ‘MBIM_CONTEXT_IP_TYPE_DEFAULT’ not handled in switch [-Werror=switch-enum]
403 | switch (ip_type) {
| ^~~~~~
|
|
mm-modem-helpers-mbim.c: In function ‘mm_modem_lock_from_mbim_pin_type’:
mm-modem-helpers-mbim.c:49:5: error: switch missing default case [-Werror=switch-default]
49 | switch (pin_type) {
| ^~~~~~
mm-modem-helpers-mbim.c: In function ‘mm_sms_state_from_mbim_message_status’:
mm-modem-helpers-mbim.c:425:5: error: switch missing default case [-Werror=switch-default]
425 | switch (status) {
| ^~~~~~
|
|
|
|
|
|
The implementation available in the shared QMI logic can be used
as-is, with one important note: if the QMI-based mode/capability
switching is used, we MUST also use QMI-based "3GPP network
registration" logic. This is needed because the MBIM command used to
select which 3GPP network to connect to allows specifying the mask of
access technologies desired, and that would overwrite whatever we had
previously set with QMI-based mode/capability switching commands.
|
|
Commit 2a97e39cdd in libmim ("libmbim-glib: add additional cause codes
to MbimNwError") added additional cause codes to MbimNwError. This
patch maps some of those MbimNwError to MMMobileEquipmentError.
This patch requires libmbim >= 1.17.1
|
|
Commit 55e40ea b1ae81a in libmbim ("libmbim-glib: add additional GMM
cause codes to MbimNwError") added one more GMM cause code to
MbimNwError. This patch maps that to MMMobileEquipmentError.
This patch requires libmbim >= 1.9.0
|
|
Commit b1ae81a in libmim ("libmbim-glib: add additional GMM cause codes
to MbimNwError") added additional GMM cause codes to MbimNwError. This
patch maps some of those MbimNwError to MMMobileEquipmentError.
This patch requires libmbim >= 1.9.0
|
|
|
|
|
