| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
On resume, refresh the EPS bearers and 3GPP registration
as the registration and bearers may expired during suspend.
|
|
|
|
MMLocation3gpp provides MCC/MNC information as integers, so it can not
make distinction between operator codes such as XXX01 and XXX001.
This commit deprecates mm_location_3gpp_get_mobile_network_code() and
implements a new function mm_location_3gpp_get_operator_code() which
provides the MCC+MNC in string format.
The mm_location_3gpp_get_mobile_country_code() is still available as
returning the MCC as an integer does not have ambiguity issues.
|
|
MNC digit count information is lost on conversion to integers. Make it
possible for the caller to get this information through a separate
boolean.
|
|
The modem may be camping in a forbidden network just for emergency
services, and we'll be able to have a MCCMNC reported in that case,
but this does not mean the modem is registered.
So, don't consider that a valid registration flag during the new
network registration request.
|
|
Print a debug message when the user provides initial eps bearer settings
that match the ones being used. This will save time to whomever is
experimenting with initial eps bearer settings.
|
|
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.
|
|
|
|
settings
We should not try to match the 'profile-id', as that setting is not
available in the input bearer settings provided by the user.
And we should not try to match the 'apn-type', as not all
implementations support it and it's not really necessary for this
purpose anyway.
|
|
|
|
When comparing bearer properties provided by the user versus loaded
from the modem, we shouldn't be very strict, e.g.:
* Password or other fields may not be readable from the device.
* Some fields may not apply at all (e.g. RM protocol for EPS bearers)
* NULL strings could be assumed equal to empty strings.
* If no explicit IP type specified, an IPv4 default may be assumed.
* If no explicit allowed auth specified, 'none' default may be
assumed.
These loose comparisons are applied when managing the initial EPS
bearer settings and status, and we keep the strict comparison only
during the connection attempt lookup of a bearer with certain
settings, as those bearer objects are all created in the same place
with the same rules.
|
|
|
|
The "Serving System" indications reported via QMI when the device is
moving may contain LAC/TAC+CID updates or just CID updates.
E.g. this one has "CID 3GPP" (0x1e):
Mon Aug 3 11:22:42 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 33
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4512 <<<<<< tlv_length = 21 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 14:C2:A8:00 <<<<<< translated = 11059732
And this one has both "CID 3GPP" (0x1e) and "LTE TAC" (0x25):
Mon Aug 3 11:23:05 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 38
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4513 <<<<<< tlv_length = 26 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 32:36:BC:00 <<<<<< translated = 12334642 <<<<<< TLV:
<<<<<< type = "LTE TAC" (0x25) <<<<<< length = 2 <<<
We should therefore allow changes only in the CID, maintaining
whatever LAC/TAC value we had before.
|
|
|
|
This is already done by the modem interface as soon as current
capabilities are loaded.
|
|
|
|
|
|
|
|
mm-iface-modem-3gpp.c: In function ‘interface_disabling_step’:
mm-iface-modem-3gpp.c:1797:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
1797 | ctx->step++;
| ~~~~~~~~~^~
...
|
|
mm-iface-modem-3gpp.c: In function ‘handle_register_auth_ready’:
mm-iface-modem-3gpp.c:550:5: error: switch missing default case [-Werror=switch-default]
550 | switch (modem_state) {
| ^~~~~~
mm-iface-modem-3gpp.c: In function ‘handle_scan_auth_ready’:
mm-iface-modem-3gpp.c:738:5: error: switch missing default case [-Werror=switch-default]
738 | switch (modem_state) {
| ^~~~~~
mm-iface-modem-3gpp.c: In function ‘interface_disabling_step’:
mm-iface-modem-3gpp.c:1788:5: error: switch missing default case [-Werror=switch-default]
1788 | switch (ctx->step) {
| ^~~~~~
mm-iface-modem-3gpp.c: In function ‘interface_enabling_step’:
mm-iface-modem-3gpp.c:2092:5: error: switch missing default case [-Werror=switch-default]
2092 | switch (ctx->step) {
| ^~~~~~
mm-iface-modem-3gpp.c: In function ‘interface_initialization_step’:
mm-iface-modem-3gpp.c:2394:5: error: switch missing default case [-Werror=switch-default]
2394 | switch (ctx->step) {
| ^~~~~~
|
|
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.
|
|
We should not assume that a manual registration request to a given
operator is successful if the modem is already registered in that
operator, because if the registration was due to an automatic process,
we cannot make sure the modem won't roam to a different network.
We should only assume that a manual registration is not needed to be
relaunched if the modem is already registered in the requested network
AND if the registration process was manual (i.e. we asked the modem to
lock into a given network).
|
|
Instead of having separate contexts for different things, setup a
interface-wide private struct.
|
|
|
|
If all CS/PS/EPS report 'denied', we should not report 'unknown' as
consolidated...
<debug> [1568556573.833928] building consolidated registration state: cs 'denied', ps 'denied', eps 'denied' --> 'unknown'
|
|
If there is one registration state which is denied and the remaining
ones are either unknown or idle, then report denied.
|
|
|
|
|
|
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/131
|
|
We use the "LTE attach status" extension defined by Microsoft to query
and monitor the initial EPS bearer settings.
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations
|
|
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.
|
|
This patch extends commit c9e85b671 ("iface-modem-3gpp: ignore initial
registration check result when appropriate") to handle the situation
where a registration check update may prematurely transition the modem
to the 'enabled' state while the modem is still being enabled.
The issue is identified by Dan Williams <dcbw@redhat.com>. More details
can be found in https://bugs.freedesktop.org/show_bug.cgi?id=106468
|
|
In mm_iface_modem_3gpp_register_in_network() when deciding whether to
force automatic registration or not, check whether the modem is already
registered in a network. Just checking whether we have a valid operator
code is not sufficient, as some modems (ublox Toby R2xx) don't always
return an operator name/code even when registered.
|
|
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.
|
|
When a modem is being enabled, an initial registration check is
scheduled to determine the current registration state and access
technology. The initial registration check is performed asynchronously
and may not complete before the modem state is transitioned to
'enabled'. When the modem is disabled shortly afterwards, the
registration state is transitioned to 'unknown' and the modem state is
transitioned to 'disabled'. But the completion of the initial
registration check after that can transition the registration state and
modem state to a wrong state. This patch addresses the issue by ignoring
a registration state update if the modem isn't already enabled or being
enabled.
|
|
|
|
to use GTask
|
|
|
|
|
|
|
|
Plugins have two ways to update signal quality and access technology
values: via unsolicited messages or via polling periodically.
Instead of keeping separate contexts for polling signal quality and
access technology values, we setup a common timeout to trigger
both. This allows us to simplify in which case the explicit update is
required, whenever one is needed to be explicitly updated, the other
one should also be.
The logic now also allows plugins to return an UNSUPPORTED error in
either load_signal_quality() and/or load_access_technologies() to tell
the interface logic that the polling of the specific item shouldn't be
performed (e.g. if the updates are expected via unsolicited messages).
If both signal quality and access technology polling is flagged as
disabled, we totally disable the polling logic internally.
The new SignalCheckContext is bound to the lifetime of the object so
that we can keep the value of the supported flags until the object is
destroyed.
|
