| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
According to QC, we should set the IP family in both the
Set IP Family and Start Network messages. After removing this
check the member is never read, only written; this means it's
effectively dead and can be removed.
|
|
Fixes a bug introduced in commit 7e386389, which caused user requested
disable operations to go to step
DISABLING_STEP_FIRST_AFTER_ENABLE_FAILED. For user requested disable,
the first step should be DISABLING_STEP_FIRST.
|
|
Telit FN980 requires more time for becoming responsive to
qmi requests after device appearance.
|
|
Querying facility locks should return a FIXED_DIALING lock if PIN2 lock
is enabled.
|
|
Prior to this CL, failure to get pin status while probing facility locks
would not flag an error. Failure to read a pin lock is a critical error
and we return it to higher layers.
|
|
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.
|
|
The cleanup was missing in one of the steps.
|
|
|
|
On QMI-capable MBIM devices, also setup the SIM hot swap logic using
QMI over MBIM, so that profile changes are detected.
|
|
The SIM hot swap setup is run during initialization and if it succeeds
it must be available throughout the whole execution of this modem
object.
So, do not cleanup the SUBSCRIBER_INFO flag on 3GPP interface disable,
which is completely unrelated to the SIM hot swap setup logic.
|
|
If enabling the subscriber info notifications fails, we should no
longer have the setup for those notifications, so make sure it's
cleaned up on error.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
This reverts commit e91f2ef315526a1a8a1b451acb5a190686b05225.
This was wrongly merged squashing multiple commits together. Reverting
to merge separate commits.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
If the device goes away while we are listing SMS messages, it may
happen that we ask the messaging interface to take a part and the
sms list object has already been disposed. Make sure the part is freed
in that case, so that we avoid memory leaks.
==19138== 6,914 (1,232 direct, 5,682 indirect) bytes in 11 blocks are definitely lost in loss record 5,282 of 5,287
==19138== at 0x483A77F: malloc (vg_replace_malloc.c:307)
==19138== by 0x5023349: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x50446FF: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x5044D6A: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x2577FC: mm_sms_part_new (mm-sms-part.c:180)
==19138== by 0x2504D0: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:385)
==19138== by 0x21A15C: add_sms_part (mm-broadband-modem-mbim.c:5169)
==19138== by 0x21A31F: sms_read_query_ready (mm-broadband-modem-mbim.c:5215)
==19138== by 0x4E600F3: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4E64638: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4D3870D: transaction_task_complete_and_free (mbim-device.c:236)
==19138== by 0x4D396B9: process_message (mbim-device.c:616)
|
|
|
|
If we had already successfully run the sim hot swap context setup
during the initial initialization, make sure we don't re-run on SIM
PIN unlock, because we may be re-creating signal handlers and such.
|
|
The function shall be needed for profile switch checking.
|
|
If we're asking for IPv4v6 and we get IPv4-only connected, we
shouldn't attempt to provide IPv6 addressing details in the bearer
object, because we would fallback to say DHCP is needed if we were not
able to load any IPv6 details from the modem.
This is, instead of provinding both IPv4 and IPv6 details:
------------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
------------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
------------------------------------
IPv6 configuration | method: dhcp
| prefix: 0
We should report only IPv4 details:
----------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
----------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
|
|
If we ask for IPv4v6 is requested but the network only grants IPv4, we
end up receiving the 'Connect Set' response with nw_error set to
'pdp-type-ipv4-only-allowed'. In this case, we should still succeed
the connection attempt and only report the IPv4 info.
We therefore change the logic to skip processing the nw_error unless
the activation state is reported as ACTIVATED or ACTIVATING.
|
|
If the new iccid is already available, reading the iccid from the
card can be skipped.
|
|
Using the 'UIM switch slot' operation, this commit introduces the
ability to change which SIM slot to be active at any given time in a
Multi-SIM Single-Standby setup.
There is no validation done on whether the selected SIM slot has a
valid SIM card inserted or not; if the user selects a slot without any
SIM card, the newly probed modem object will start in Failed state
right away.
|
|
This commit introduces Multi-SIM Single-Standby support in all QMI
capable devices that support multiple SIM slots.
The 'UIM Get Slot Status' method is used to list all available
physical slots as well as the availability of SIM cards in the
different slots. This method also provides UICC already, so the SIM
objects are created early and exposed early in DBus.
Once all slots are listed, the logic will briefly make each of the
available SIM cards active in order to read additional settings like
IMSI, MCCMNC or the Operator name. This brief switching is required
because in a Single-Standby setup only one SIM can be active at any
given time.
The last slot to probe is always the one that was active originally,
making sure that the modem initialization logic can go on with the
correct SIM slot.
|
|
During the base SIM initialization process, where we ask the modem for
the properties of the currently primary active SIM, we need to make
sure that the SIM is ready before attempting to query this
information.
This explicit wait is required when loading properties for non
active SIMs during the short period of time when they're made active.
|
|
The default SIM creation method will attempt to initialize the SIM
properties during the object creation.
This new method allows creating SIM objects with already known
property values, and therefore not explicitly running the
asynchronous initialization process.
Completely equivalent to mm_base_sim_new_initialized() but creating a
subclassed MMSimQmi instead of the generic MMBaseSim.
|
|
The original logic that parsed the 'UIM Get Card Status Output' did a
bit of guessing to decide what was the current lock status to consider
in the modem. This guessing was fine on systems with a single SIM
slot, but it was very wrong as soon as multiple SIMs had to be
considered.
In a Multi-SIM Multi-Standby setup, with multiple SIMs reported as
active, we should look for the one flagged as "GW primary" to consider
it the primary SIM card of the system,the one required to start a data
connection.
We explicitly ignore the ones flagged as "1X primary", as we don't
consider a SIM card required in CDMA/EVDO setups.
|
|
This is going to be used in handling the multi-SIM setup, so make it a
common helper.
|
|
This new method allows changing the SIM slot considered as primary,
when the modem supports multiple SIM slots.
The generic handling of this method will make sure that the modem
object and all its SIM objects are re-probed from scratch as soon as a
successful SIM slot switch happens.
Implementations may report MM_CORE_ERROR_EXISTS when the switch
doesn't need to happen (e.g. if the requested SIM slot is already the
active one).
|
|
When the SIM switch doesn't happen as part of an async hot swap
detection, we should trigger the switch handling at base modem level,
which e.g. doesn't require explicit cleanup of the SIM hot swap
detection port context.
|
|
The 'SimSlots' property exposes an array of SIM object paths, with one
array item for each available SIM slot in the system. If a valid SIM
card is found in a given slot, the path of the SIM object will be
exposed in the array item; if no valid SIM card is found, the empty
object path ("/") will be exposed instead.
The 'PrimarySimSlot' property exposes which of the SIM slots available
in the system is the one configured as being primary. In a Multi-SIM
Single-Standby setup, the primary slot will be the one corresponding
to the single active SIM in the system. In a Multi-SIM Multi-Standby
setup, the primary slot will be the one configured to act as primary
(e.g. the one that will be used for the data connection) among all the
active SIM cards found.
|
|
Before attempting to load any SIM property value, allow checking
whether the SIM is ready for operation or not.
This action is implicitly done by the "unlock required check" step
that is triggered before initializing the primary SIM card, but it
would not be done when initializing other available SIM cards.
|
|
The default SIM creation method will attempt to initialize the SIM
properties during the object creation.
This new method allows creating SIM objects with already known
property values, and therefore not explicitly running the
asynchronous initialization process.
|
|
This new property helps us identify in which SIM slot the SIM card is
inserted, when multiple slots are available, in the [1,N] range.
For the single-SIM systems this value will always be '0'.
This property is not publicly exposed in DBus, it is considered an
implementation detail.
|
|
If a SIM is inactive we cannot perform any SIM-PIN or SIM-PUK related
operation with it.
|
|
In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
|
|
Fixes incoming SMS translation issue seen on MC7354 when translating
contents from Latin-1 encoding to UTF-8, because the encoding parameter
"ISO−8859−1" used U+2212 (MINUS SIGN) instead of U+002D (HYPHEN-MINUS).
[mm-sms-part-cdma.c:873] read_bearer_data_user_data():
text/data: ignored (latin to UTF-8 conversion error): 0:
Conversion from character set 'ISO−8859−1' to 'UTF-8' is
not supported
Fix thanks to Peter Hunt
|
|
Despite 3GPP TS 23.038 specifies that Unicode SMS messages are
encoded in UCS-2, UTF-16 encoding is commonly used instead on many
modern platforms to allow encoding code points that fall outside the
Basic Multilingual Plane (BMP), such as Emoji.
Update the logic to always use UTF-16 instead of UCS-2 when creating
or parsing PDUs (even if we always report as sending or receiving
UCS-2). For all purposes, UCS-2 is considered a subset of UTF-16
(assuming that code points out of the [U+0000,U+D7FF] and
[U+E000,U+FFFF] ranges are not applicable in UCS-2).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/250
|
|
Mostly to use GLib types like gchar or gint, and also to use
G_N_ELEMENTS() instead of custom end of array terminating items.
|
|
Just as an implementation detail to be taken as an extension of
UCS2BE, never really to be used as a real modem charset.
|
|
|
|
Only applicable when building with WITH_NEWEST_QMI_COMMANDS.
mm-broadband-modem-qmi.c:4741:1: error: ‘common_enable_disable_unsolicited_events_signal_strength’ defined but not used [-Werror=unused-function]
4741 | common_enable_disable_unsolicited_events_signal_strength (GTask *task)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:4528:1: error: ‘serving_system_indication_cb’ defined but not used [-Werror=unused-function]
4528 | serving_system_indication_cb (QmiClientNas *client,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:3468:1: error: ‘common_enable_disable_unsolicited_registration_events_serving_system’ defined but not used [-Werror=unused-function]
3468 | common_enable_disable_unsolicited_registration_events_serving_system (GTask *task)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:2812:1: error: ‘get_serving_system_3gpp_ready’ defined but not used [-Werror=unused-function]
2812 | get_serving_system_3gpp_ready (QmiClientNas *client,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm-broadband-modem-qmi.c:1652:1: error: ‘get_signal_strength_ready’ defined but not used [-Werror=unused-function]
1652 | get_signal_strength_ready (QmiClientNas *client,
|
|
Only applicable when building with WITH_NEWEST_QMI_COMMANDS.
mm-broadband-modem-qmi.c: In function ‘process_common_info’:
mm-broadband-modem-qmi.c:2924:20: error: comparison is always false due to limited range of data type [-Werror=type-limits]
2924 | if (mnc[2] == 0xFF) {
| ^~
|
|
If splitting the +CPMS=? response in groups fails, make sure we set
the GError when returning FALSE.
|
|
If the connection attempt is aborted before finishing (either network
triggered or user triggered), we need to make sure that we run a 'Stop
Network' request for every 'Start Network' that had succeeded until
then, or otherwise we'll no longer be able to re-run a 'Start Network'
with the same settings and get a proper packet data handle.
E.g. in this sequence we attempt a IPv4v6 connection. The logic starts
setting up the IPv4 path:
Wed Jul 29 14:44:06 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:06 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
...
The 'Start Network' for IPv4 succeeds and we get a proper packet data
handle:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3075 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3075 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = SUCCESS <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 80:CD:AD:81 <<<<<< translated = 2175651200
Then, we start the IPv6 connection path:
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Running IPv6 connection setup
...
But, because we suddenly are not registered in the network, the
connection is aborted, and we don't cleanup the IPv4 path at this
point, as this patch wasn't available.
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Bearer not allowed to connect, not registered in 3GPP network
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Forcing disconnection of bearer '/org/freedesktop/ModemManager1/Bearer/56'
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: transaction 0xe1 aborted, but message is not abortable
Wed Jul 29 14:44:07 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> enabled)
Wed Jul 29 14:44:07 2020 daemon.debug [1567]: <debug> Couldn't connect bearer '/org/freedesktop/ModemManager1/Bearer/56': 'operation cancelled'
We then attempt a new connection request with the same settings:
Wed Jul 29 14:44:22 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Launching connection with QMI port (usb/cdc-wdm0) and data port (net/wwan0)
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Defaulting to use static IP method
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: <debug> Running IPv4 connection setup
And we see how the 'Start Network' command fails with a 'No Effect'
error, as the IPv4 was left connected earlier. Due to this, the modem
is assumed connected, but we won't have a valid packet data handle to
stop the connection cleanly:
Wed Jul 29 14:44:22 2020 daemon.debug [1567]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 3080 <<<<<< tlv_length = 11 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet
Wed Jul 29 14:44:23 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 20 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 3080 <<<<<< tlv_length = 14 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:1A:00 <<<<<< translated = FAILURE: NoEffect <<<<<< TLV: <<<<<< type = "Packet Data Handle" (0x01) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = 0
|
|
If the modem is connected and we receive indications of a quick
unregistration cycle (i.e. unregistered, then registered again) we
should not end up flagging the modem as disconnected.
We already had some logic to avoid this with the "deferred 3GPP
unregistration" logic in the base bearer object, but this logic only
took into account the status of the bearer, not the status of the
modem.
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (home -> idle)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '0', MNC: '0', Location area code: '0', Tracking area code: '1CE8', Cell ID: '68F832')
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Connected bearer not registered in 3GPP network
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> enabled)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (0)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: access technology changed (lte -> unknown)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Periodic signal checks disabled
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle -> registering)
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '0', MNC: '0', Location area code: '0', Tracking area code: '1C84', Cell ID: 'A3E050')
Wed Jul 29 15:35:44 2020 daemon.debug [1567]: <debug> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location updated (MCC: '238', MNC: '1', Location area code: '0', Tracking area code: '1C84', Cell ID: 'A3E050')
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home)
Wed Jul 29 15:35:44 2020 daemon.info [1567]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabled -> registered)
We now try to improve this situation by also considering the case
where modem is supposed to get into "enabled" state (i.e. not
registered, not searching), but we still consider the amount of
connected bearers to decide the final state reported by the modem. In
other words, a modem with the 3GPP registration reported as 'idle'
will still be reported as 'connected' if there is at least one bearer
in connected state. This situation will end as soon as the 'deferred
3GPP unregistration' timeout expires, as that will force the bearer to
be disconnected.
|
|
|
|
|
