If the device supports multiple SIM slots, when the user provides a
PATH or INDEX of a SIM card to use, don't look for the SIM object only
in the 'Sim' property, also look for it in the 'SimSlots' property.
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.
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
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 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.
There was a limitation in the past in the plugin, because one of the steps
during the dial (CONNECT_3GPP_CONTEXT_STEP_PDP_CTX) was to reconfigure a
specific CID hardcoding the IP type to IPv4.
That logic was removed in commit af2d6c1c4b,
but we didn't remove the IPv4 limitation at that point.
some ITM family modems require full parameters:
AT^SGAUTH=cid,type,user,pwd
even when type is AUTH_NONE.
Fortunately, all modules of the IMT family tolerate this syntax,
so it can be adopted for the entire family.
the AT^SCFG="Radio/Band" command does not return a different answer
for different charsets.
This code was working previously because the charset was left to default (GSM)
at the time of this operation, and therefore the string was unchanged anyway.
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-broadband-modem-qmi.c: In function 'process_common_info':
mm-broadband-modem-qmi.c:2897:30: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
/* both apply */ ;
^
Signed-off-by: Justin Standring <justin.standring@taitradio.com>
mm-broadband-modem-qmi.c: In function 'common_signal_info_get_quality':
mm-broadband-modem-qmi.c:1469:21: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "RSSI (CDMA): %d dBm", cdma1x_rssi);
^~~~
mm-broadband-modem-qmi.c:1469:21: note: each undeclared identifier is reported only once for each function it appears in
mm_obj_dbg (self, "RSSI (CDMA): %d dBm", cdma1x_rssi);
^~~~
mm-broadband-modem-qmi.c: In function 'process_gsm_info':
mm-broadband-modem-qmi.c:2992:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no GSM service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'process_wcdma_info':
mm-broadband-modem-qmi.c:3100:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no WCDMA service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'process_lte_info':
mm-broadband-modem-qmi.c:3209:25: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "no LTE service reported");
^~~~
mm-broadband-modem-qmi.c: In function 'config_signal_info_ready':
mm-broadband-modem-qmi.c:4890:21: error: 'self' undeclared (first use in this function)
mm_obj_dbg (self, "QMI operation failed: '%s'", error->message);
^~~~
Signed-off-by: Justin Standring <justin.standring@taitradio.com>
The ELS61 doesn't like authentication given without quotes:
[modem3/ttyACM1/at] --> 'AT^SGAUTH=8,1,tm,t-mobile<CR>'
[modem3/ttyACM1/at] <-- '<CR><LF>+CME ERROR: 4<CR><LF>'
Only when user/pass strings are quoted it works:
[modem6/ttyACM1/at] --> 'AT^SGAUTH=8,1,"t-mobile","tm"<CR>'
[modem6/ttyACM1/at] <-- '<CR><LF>OK<CR><LF>'
It's critical not to timeout early on devices with AT ports, or we may
end up flagging the modem as invalid.
ModemManager[26829]: <debug> [1593097973.552712] [modem1/ttyACM0/at] --> 'AT^SWWAN=1,2,1<CR>'
....
ModemManager[26829]: <debug> [1593098064.195217] [modem1] couldn't connect bearer: Serial command timed out
....
ModemManager[26829]: <error> [1593098091.167987] [modem1] port ttyACM0 timed out 10 consecutive times, marking modem as invalid