| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
This is required in order to be able to use a custom bearer which in
turn is necessary for establishing ECM connections.
|
|
Quectel modems report only their major firmware version through
AT+GMR, use AT+QGMR instead to report the full firmware version.
|
|
Quectel EG25-G QMI modem firmware revisions are not matched with carrier configs.
Different VoLTE profiles might be selected by the user causing
the carrier config revision to change.
Since fwupd uses this string for firmware updates, it gets confused and
thinks the user has an update available.
|
|
|
|
|
|
|
|
methods
|
|
|
|
|
|
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/483
|
|
|
|
When we have just enabled, we want to give it some time before
starting the registration process, so that any pending registration
update that may have been scheduled during the enabling phase is
applied. We don't want to trigger a new automatic registration if
e.g. we're already registered.
|
|
The 'ENABLE + 1' step is 'WAIT_FOR_ENABLED' really, and that should be
only used when the current state is not a final one. If we're already
enabled, or registered, or connected, then jump to 'REGISTER' right
away.
|
|
During the enabling phase, the modem may receive a lot of asynchronous
updates reporting registration info changes, but we were fully
ignoring them because the modem was not yet enabled. The problem with
this is that as soon as we reach the enabled state, we may not receive
additional info, so we would be left in 'enabled' state until new
asynchronous updates are received or until we start a connection
attempt.
We can solve this by triggering an explicit update with the
registration information that we have cached as soon as we're enabled.
|
|
|
|
|
|
Only if transitioning into a "registered" state ("home", "roaming",
"partner") or if "denied"; otherwise, assume LAC/TAC/CID are all
unknown.
This change makes the logic also reload the location info on
registration updates reported asynchronously via notifications.
|
|
The profile management APIs implemented by Microsoft in the MBIM
extensions provide certain features that are not available via other
means (e.g. ip type, access type preference, roaming allowance...).
Unfortunately, these APIs require the current list of profiles
installed in the modem to be a bit special; e.g. with one profile max
for each context/APN type. If this does not happen, the operations
will fail, or they will update contexts that should not be updated.
So, we disable for now the MBIM extension profile management support;
the logic is there, but not used by default.
|
|
In order to show the properties of the profile management interface, e.g.:
$ sudo mmcli -m a --3gpp-profile-manager-status
-----------------------------------
3GPP profile manager | index field: apn-type
|
|
Instead of expecting a specific profile id, allow the command to
support different index field types.
|
|
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
|
|
|
|
|
|
For most protocols, the operations to manage profiles require a unique
'profile-id' as index. This applies to AT, QMI and generic MBIM.
But for MBIM using the Microsoft Extensions for profile management,
this is no longer true; the device expects the 'apn-type' to be the
index.
This new property lets the user know which is the expected index field
in the Delete() and Set() operations.
|
|
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.
|
|
At least not yet.
|
|
At least not yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not applicable to bearer properties, as this is exclusively a proflie
management setting, unrelated to connection attempts.
|
|
|
|
Not applicable to bearer properties, as this is exclusively a proflie
management setting, unrelated to connection attempts.
|
