| Age | Commit message (Collapse) | Author |
|---|
|
Adding support for carrier lock for MBIM modems using google simlock
mechanism.
|
|
When a request to disable the modem arrives while the packet service
state wait is ongoing we were not correctly cancelling the operation.
The main reason for this is that this operation does not change the
modem state, and so the "wait for final state" logic in the disabling
sequence was not being considered.
We solve this by plugging in the Simple.Connect() operation
cancellable in the wait for packet service state operation. The
connection attempt will be cancelled during the disabling sequence as
well, and when that happens we will explicitly halt the packet service
state wait as well.
|
|
In certain protocols like QMI or MBIM we may be able to report an
exact packet service state, so there is no need to guess it, as the
guess may not always be right.
The logic will track automatically whether modem-reported packet
service states are available, and use them if so. Otherwise, it'll try
to guess as we were doing before (e.g. if registered in EPS, packet
service is considered attached).
|
|
Provide a new internal method in the 3GPP interface to request an
explicit packet service state update.
|
|
When processing QMI and MBIM messages to report domain registration
updates, we should do that altogether so that we don't report bogus
transitions to idle if the registration state switches from one domain
to another.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/629
|
|
|
|
ModemManager handles suspend and resume signals sent from powerd
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/547
|
|
|
|
|
|
Includes updates by Aleksander Morgado to fix coding style issues and
to place this logic in the correct interface.
|
|
On resume, refresh the EPS bearers and 3GPP registration
as the registration and bearers may expired during suspend.
|
|
The action of disabling facility locks is user-triggered, so there is
no need to have an internal method to run the logic without user
interaction.
|
|
|
|
|
|
|
|
So that the logic looking for 3GPP related registration info works in
the QMI modem object when selected network is reported as 'unknown'
but still the radio interfaces list reports 5GNR.
<<<<<< TLV:
<<<<<< type = "Serving System" (0x01)
<<<<<< length = 6
<<<<<< value = 01:02:01:00:01:0C
<<<<<< translated = [ registration_state = 'registered' cs_attach_state = 'detached' ps_attach_state = 'attached' selected_network = 'unknown' radio_interfaces = '{ [0] = '5gnr '}' ]
|
|
|
|
The request for forced registration is an implementation detail of
mm_iface_modem_3gpp_register_in_network(), not part of any state to
keep in the private info.
|
|
This is going to be used by modems that require this operation
e.g. after changing access technology or bands.
|
|
This method allows users to modify the settings used during the
initial LTE attach procedure.
|
|
This property shows the settings stored in the device to be used
during the initial LTE attach procedure.
|
|
This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
|
|
|
|
This patch adds a 'Pco' property to the Modem3gpp interface for tracking
PCOs that the modem has received from the network.
|
|
The "location area code" field is given in GSM/UMTS networks
exclusively. LTE networks use the concept of "tracking area code"
instead.
This patch updates the Location interface to Provide separate fields
for LAC and TAC, instead of giving TAC values in the LAC field.
|
|
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
|
|
|
|
|
|
Plugins may decide which facility locks can be completely skipped from the list
being checked.
|
|
This patch adds the support for solicited/unsolicited EPS network
registration status via AT+CEREG, which is configurable via the
'iface-modem-3gpp-eps-network-supported' property of the
MMIfaceModem3gpp interface and is disabled by default.
|
|
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
|
|
Call managers all want to be able to set the operator ID and/or name as soon as
we get registered. We will consider now that whenever we get into registered
state we already have operator code and name updated to the proper values.
Applications shouldn't, though, just rely on those values to be valid as long as
we're registered, as the modem may re-register automatically in some other
network (e.g. going from a roaming network to the home network).
This change involves not setting the state to REGISTERED until operator name
and code loading sequences have been run. We will still signal in the log the
change, with a new 'registering' intermediate state indication.
|
|
|
|
In the generic broadband modem implementation we'll just implement the specific
command to request auto/manual network registration, and we leave all the other
logic (waiting for the new registration status and all that) in the interface,
as it is really common for every possible implementation.
|
|
Once upon a time it was a good idea to have separate steps for CS and PS related
actions, so that plugins could override specific steps with a great detail. That
idea turned out to be not very useful, as the only case which requires custom
CS/PS registration actions is the QMI-enabled modem, and that one has commands
to act on both registration actions at the same time. So, we now consolidate
all steps, so that the implementation of the interface needs to provide all the
logic to setup/enable/disable/cleanup/check registrations in each mode.
Also, we consolidate how the unsolicited registration messages are handled, so
that it's equivalent to other unsolicited messages:
* 'Setup' will configure ports to process the unsolicited messages.
* 'Enable' will tell the modem to send unsolicited messages.
* 'Disable' will tell the modem not to send unsolicited messages.
* 'Cleanup will configure ports to ignore the unsolicited messages.
|
|
The previous logic would first request to check if indicators were supported,
and only then allow to setup/enable/cleanup/disable unsolicited events. This
behaviour is very specific to the generic 3GPP case, and therefore it shouldn't
be handled in the even more generic 3GPP interface. The logic is still kept,
but handled within the MMBroadbandModem object.
|
|
|
|
|
|
Renamed `MMCommonSimpleProperties' to `MMSimpleStatus', and removed the
`MMSimpleStatusProperties' provided in libmm-glib. We'll just use the original
one from libmm-common always.
|
|
|
|
|
|
They will all get it themselves.
|
|
Configuring unsolicited events involves:
* Setup unsolicited events. This handles the setup of the unsolicited message
handlers in the AT ports, including the setup of the callback to get called
when the unsolicited messages are received.
* Enable unsolicited events. This tells the modem to actually send the
unsolicited messages.
* Disable unsolicited events. This tells the modem to stop sending unsolicited
messages.
* Cleanup unsolicited events. This removes the unsolicited message handlers
in the AT ports.
|
|
|
|
|
|
|
|
|
|
We may want to do some checks while creating a new bearer.
|
|
E.g, Iridium modems won't support PS networks, and LTE-only modems won't support
CS networks.
|
|
But provide a consolidate state in the interface.
|
